Hard Software Testing Interview Questions

Success, failure and pending flows, timeouts, refunds, double-click payments, every method (UPI, cards, net banking), rounding, security (no card data stored) and reconciliation with bank reports.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.

Use mocks or stubs from the API contract such as Swagger, write test cases early and validate again when the real service is available.

Reproduce and assess impact, inform stakeholders, help developers fix and verify in staging, run regression and check monitoring after the hotfix, then do a post-mortem.

Check SQL injection, brute-force lockout, password masking, session timeout, HTTPS, cookie flags, error messages not revealing users and password reset flow.

Use data, not opinion. Show defects caught before release by severity, production incidents and their cost, and defect leakage trends. Explain what risk increases if testing is cut, then offer options: risk-based testing of critical flows, more automation for regression, and developers owning unit tests. Agree on which risks the business accepts in writing. This turns the discussion into a trade-off decision instead of a conflict.

Cause-effect graphing is a black box technique that models input conditions (causes) and output actions (effects) with logical relations like AND, OR and NOT. The graph is converted into a decision table, and each column becomes a test case. It is useful when outputs depend on combinations of inputs, such as loan approval based on income, age and credit score. It helps find missing or contradictory rules in the requirement.

The classification tree method breaks the input domain into classifications (aspects like payment type, user type, device) and classes (values like card, UPI, wallet). These are drawn as a tree, and test cases are formed by picking one class from each classification in a combination table. It makes coverage visible, helps reviewers spot missing classes and combines well with pairwise selection to keep the number of test cases manageable.

Build a permission matrix with roles as rows and actions as columns, such as create, edit, delete, publish and view, marking allowed or denied from the requirement. Write a positive test for each allowed cell and a negative test for each denied one. Test through the UI and also call the APIs directly, because hidden buttons are not security. Check role changes take effect immediately and that users cannot access other users' data by changing IDs.

Test both states: flag on and flag off, so existing users are not affected. Verify the targeting rule assigns the right users and that a user stays consistently in the same group. Test switching the flag on and off in a live session and confirm data created with the flag on still works after it is turned off. Check analytics events for both groups and confirm the flag can be rolled back quickly.

Look at requirement coverage through the traceability matrix, the share of defects found by scripted tests versus exploratory testing or production, and defect leakage per module. Review samples for clear objectives, correct expected results and use of techniques like boundaries and negative cases. Track how many cases were updated or retired after changes. If many production bugs map to areas with passing tests, the design, not the execution, needs improvement.

Collect exact details: user, time, device, browser and request IDs. Compare production with QA for configuration, feature flags, data volume, third-party integrations, versions and caching. Ask for production logs and error traces through the support or dev team. Try to reproduce in QA with production-like data or in a staging environment. Once found, add a test for the gap and fix the environment difference if one caused it.

Stop the retest loop and call a short session with the developer, lead and product owner. Check whether the fix addresses the root cause or only the symptom, whether everyone agrees on the expected behaviour and whether different environments or data are involved. Run a root cause analysis and agree on clear acceptance tests before the next fix. Add an automated regression check so it cannot silently return.

Run a backlog grooming session with the product owner. Close bugs that are obsolete, no longer reproducible or for retired features. Merge duplicates. Group the rest by module and user impact, and ask whether a few related bugs can be fixed together as one story. Agree to reserve a small share of each sprint for bug fixes. Set an ageing rule, for example review any bug older than 90 days.

Defect prevention focuses on stopping defects from being introduced instead of only finding them. Practical techniques include requirement reviews and clear acceptance criteria, Three Amigos sessions, design and code reviews, unit testing standards, coding checklists from past bugs, root cause analysis of escaped defects, and training on common mistakes. Track whether repeated defect types fall over time to prove the effort works.

Keep it short and decision-oriented. Show open bugs by severity, the created versus resolved trend, blockers with owners and dates, defect leakage from the last release and modules with the most defects. Give a clear recommendation, such as ready, ready with known issues or not ready, with reasons. Use a shared dashboard for detail, and one slide or email summary for leaders who need only the risk picture.

A transaction groups several database operations so they all succeed or all fail together, following ACID properties. To test rollback, force a failure in the middle of a multi-step action, for example a money transfer where the credit step fails after the debit. Then query both accounts and confirm neither balance changed and no partial records exist. Also check the user sees a clear error and can retry safely.

An operation is idempotent if repeating the same request gives the same result as doing it once. GET, PUT and DELETE should be idempotent; POST usually is not. To test, send the same request several times and check the server state does not change after the first call. For payments, check that retrying with the same idempotency key does not create a second charge, which protects users during network retries.

Find the documented limit, for example 100 requests per minute per key. Send requests just below and above the limit and check that extra requests get 429 Too Many Requests with a Retry-After header. Verify the counter resets after the window and that limits apply per key or per IP as designed. Check that one user hitting the limit does not block others, and that normal traffic is not throttled.

Start small. Agree on a definition of ready and definition of done that include acceptance criteria and testing. Join refinement and run Three Amigos for every story. Set up a simple bug workflow and severity guide in the tracker, a shared test case repository and a smoke checklist for each build. Then add API checks and automated regression for stable flows. Review what works in each retrospective and adjust.

Mutation testing measures the quality of a test suite. A tool makes small changes, called mutants, to the code, such as changing greater than to greater than or equal, and runs the tests. If a test fails, the mutant is killed; if all tests still pass, the mutant survived, which shows a weak spot in the tests. The mutation score is killed mutants divided by total mutants. It is strong but slow, so teams apply it to critical modules.

Contract testing checks that a service provider and its consumers agree on the API format, such as request fields, response fields and status codes, without running a full end-to-end environment. The consumer defines what it expects, and the provider's build verifies it still meets that contract. It catches breaking changes early in microservice systems, where full integration environments are slow and fragile.

Compare record counts per table before and after. Check field mapping, data types, formats, encodings and default values for a sample of records, including edge cases like nulls, special characters and very old records. Verify relationships are kept, such as each order still linked to its customer. Run key business reports in both systems and compare totals. Test the rollback plan and confirm the new application works with migrated data.

Operational acceptance testing checks that the system is ready to be run and supported in production: backup and restore, failover, monitoring and alerts, deployment and rollback scripts, log access, security patches and support runbooks. UAT checks that the system meets business users' needs. OAT is done with operations or SRE teams, UAT with business users. Both must pass before a major go-live.

Ask the developer which code, services and database tables changed. Map them to impacted flows: all payment methods, refunds, partial payments, failed payment retries, invoices and order status updates. Add high-risk areas from past defects and anything that calls the same service. Run full payment regression because the business risk is high, plus a smoke test of the rest of the application before release.

Explain the risk: system testing proves the software matches the specification, but only users confirm it fits real business work. Propose a lighter option instead of none: a short, focused UAT on critical flows with two or three key users, or a staged rollout to a small user group with monitoring and quick rollback. If they still skip it, record the decision and the accepted risks with the product owner.

Three-point estimation uses an optimistic (O), most likely (M) and pessimistic (P) estimate for each task. The weighted formula is (O + 4M + P) divided by 6. If testing a module would take 4 days at best, 6 days most likely and 14 days at worst, the estimate is (4 + 24 + 14) / 6 = 7 days. It includes uncertainty in a single number and is often combined with a work breakdown of test activities.

Product risks are about the quality of the software itself: features that may fail and harm users, such as wrong interest calculation or a data leak. They decide what to test more deeply. Project risks are about running the test project: late builds, unstable environments, missing skills, unclear requirements or tight deadlines. They decide how to plan, with mitigations like buffers, backup environments or training.

Model answer: Situation: a regulatory change had to go live in ten days. Task: lead four testers. Action: I split work by risk, put our strongest tester on the calculation engine, ran daily 15-minute bug triage with developers and shared a single status dashboard. I also automated the repeated tax checks. Result: we released on the deadline with zero critical defects, and the client used our test evidence for their audit.

Identify the integration points and the service's sandbox, limits and test data. Plan to test with a mock or stub early for our logic and error handling, then against the real sandbox for integration. Include failure scenarios: timeout, slow responses, invalid data and the service being down. Add the dependency to the risk list, with contacts and a fallback plan, and confirm production credentials and monitoring before go-live.

A QA lead reviews requirements and plans testing, including scope, estimates, resources and risks. They assign work, set standards for test cases and bug reports, and review test artefacts. During execution, they track progress, run triage and remove blockers. At the end, they give a clear release recommendation, prepare closure reports and drive lessons learned. They also mentor the team and improve the process over time.

A go or no-go meeting is held before release to decide whether to deploy. QA presents test coverage against scope, pass and fail counts, open defects by severity with their impact, known issues and workarounds, any untested areas and the overall risk. QA gives a recommendation, but the business owner decides. The decision and accepted risks should be recorded in the meeting notes.

Keep a tiered regression suite: a smoke set for every build, a core set of critical flows for every release and a full set run on a rotation or before major releases. Each month, add impact-based tests from the release changes and cases for recent production bugs. Automate stable, repeated cases and keep manual effort for new or changing areas. Schedule regression early enough to fix and retest found issues.

Do not copy raw production data into test environments. Use synthetic data generated for the test cases, or masked production data where names, phone numbers, emails, ID numbers and card details are replaced while formats and relationships are kept. Restrict access to test databases and record the data rules in the test plan. This keeps testing realistic and follows India's data protection law and company policy.

Model answer: Situation: a loan app release was planned on Friday, but the EMI schedule showed wrong values for some tenures. Task: give an honest recommendation. Action: I presented the failing cases, the number of affected customers and the compliance risk in the go or no-go meeting, and proposed a three-day delay with a fix plan. Result: management agreed, the fix shipped on Monday, and no complaints came in.

Use the app's analytics, or market data if it is a new app, to find the top devices, OS versions and screen sizes. In India, cover a strong share of budget and mid-range Android phones with low RAM, a few manufacturers' custom Android skins, the two or three latest Android versions, and recent iPhones if iOS is supported. Add a tablet if relevant. Review the matrix each quarter and use a cloud device lab for wider coverage.

Reproduce it on that exact OS version, using a real device or an emulator image, and note the device model and app build. Capture the crash log and stack trace. Check if the code uses an API or library not supported on that version, or a permission or storage behaviour that changed. Log the bug with logs and the minimum supported version from the requirement, so the team can decide to fix it or raise the minimum version.

Use the platform's sandbox or test accounts so no real money is charged. Test a successful purchase, cancellation, payment failure, pending payment, refund and restoring purchases on a new device. For subscriptions, test free trial, renewal, upgrade, downgrade, expiry and grace period, often with shortened test durations. Verify the server records the purchase and unlocks features, and that killing the app mid-purchase does not lose it.

Turn off the network and perform supported actions, such as creating, editing and deleting records, and check they are saved locally with a pending status. Reconnect and verify everything syncs once, in order, with no duplicates. Test conflicts, where the same record is changed on two devices, and confirm the agreed rule applies. Test sync after app restart, on a slow network and when the server rejects a change.

A cold start launches the app from scratch when it is not in memory, loading the process and the first screen; it is the slowest. A warm start happens when the app process exists but the screen must be recreated, and a hot start just brings it to the foreground. Users abandon slow apps, so teams set targets, such as cold start under two seconds on a mid-range device, and measure each release for regressions.

Check that sensitive data like tokens and personal details are not stored in plain text on the device or written to logs. Verify all traffic uses HTTPS and the app rejects invalid certificates. Check session timeout, logout clearing data and that sensitive screens block screenshots if required. Test behaviour on rooted or jailbroken devices if the policy needs it, and that API keys are not visible in the app package.

Collect details from reviews and support: devices, OS versions and app version when it started. Compare battery usage of the current and previous versions on the same devices over a typical session and while idle in background. Use profiling tools to look for background location, wake locks, frequent sync or network polling. Share measurements with developers, verify the fix with the same method, and add a battery check to release testing.

Model answer: Situation: a new fresher on my team was writing very long, unclear bug reports. Task: help her improve quickly. Action: I reviewed five of her bugs with her, showed a simple template, paired with her on two exploratory sessions and gave weekly feedback. Result: within a month developers stopped asking her for clarification, and she later found and reported a major session bug on her own.

A workload model describes the realistic load to simulate: which user journeys run, their mix in percentages, the number of concurrent users, request rates, think times, data volumes and the ramp-up pattern. For example, 60 percent browse, 25 percent search, 10 percent add to cart and 5 percent checkout at a peak of 2,000 concurrent users. It is built from production analytics and business forecasts, and wrong models produce meaningless results.

The result is a failure, not a pass. Failed requests often return quickly, so they make response times look better than they are. Check which requests fail and with which errors, such as 500, 503 or timeouts, and when errors started relative to the load level. Look at server logs, connection pool and thread limits. Also confirm the script is not wrong, for example expired tokens or bad test data.

Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request to a site, such as changing their email, because the browser automatically includes cookies. Prevention includes anti-CSRF tokens in forms, SameSite cookie settings and re-authentication for sensitive actions. Testers check that state-changing requests fail when the token is missing or reused, and that such actions are not done through GET requests.

This is an insecure direct object reference, a form of broken access control and a critical security bug, because any user can read other users' data. Stop exploring further beyond what is needed to confirm it, record the request, accounts used and evidence, and log it as a critical bug with restricted visibility. Inform the lead and security contact immediately. The fix is a server-side ownership check on every request.

Vulnerability scanning uses automated tools to look for known weaknesses, such as outdated libraries, missing security headers or open ports. It is fast, repeatable and can run in the pipeline, but gives false positives. Penetration testing is a deeper, mostly manual exercise by security experts who try to exploit weaknesses and chain them like a real attacker. Teams scan regularly and run penetration tests before major releases or yearly.

Start with low-cost steps. Add an OWASP-based security checklist to the definition of done for stories touching login, payments or personal data. Train testers on access control, injection and session checks. Add automated dependency and vulnerability scans to the CI pipeline. Include negative authorization tests in API suites. Arrange a penetration test before major releases and track security bugs separately with clear severity rules.

A stored procedure is a named block of SQL logic saved in the database and called with parameters, for example a procedure that calculates monthly interest. To test it, call it with valid, boundary and invalid inputs, check the returned values or result sets, verify the rows it inserts or updates, check error handling for bad parameters and confirm it rolls back on failure. Also check its run time with realistic data volumes.

ETL testing validates data that is Extracted from source systems, Transformed by business rules and Loaded into a target such as a data warehouse. It is a specialised form of database testing. Checks include source-to-target row counts, transformation rules such as currency conversion, handling of NULLs and duplicates, rejected-record logs, incremental loads that pick up only new changes and reconciliation of totals between source and target.

A deadlock happens when two transactions each hold a lock the other needs, so neither can continue. The database detects it and kills one transaction with an error. During testing it usually appears under concurrent load, for example two users booking the last seats at once, as random failures or 'deadlock detected' entries in logs. Testers report the exact actions and timing, and developers fix it with consistent lock order or shorter transactions.

Isolation levels control how much one transaction can see of another's uncommitted work. Common levels are Read Uncommitted, Read Committed, Repeatable Read and Serializable. A dirty read is reading data another transaction changed but has not committed; if it rolls back, you acted on data that never existed. Testers check isolation using two database sessions: update without committing in one and query in the other to see what is visible.

Open the same record in two sessions, change different fields and save both, then change the same field and save both. Check the database to see which value won and whether data was silently lost. A good design uses optimistic locking, where the second save fails with a 'record changed, please reload' message because a version column changed. Also repeat with API calls fired together to catch timing issues the UI hides.

Query the users table after signup and confirm the password is not stored in plain text or reversible encoding, but as a salted hash from a slow algorithm such as bcrypt or Argon2. Two users with the same password should have different hashes. Check that card numbers are not stored at all or are tokenised, that personal data like Aadhaar numbers is masked or encrypted, and that logs and audit tables do not copy the raw values.

Get the migration script or change list. Compare the schema before and after: new tables and columns, data types, lengths, default values, NULL rules, indexes and constraints. Check that existing data was migrated correctly, for example a new status column filled for old rows. Run the main app flows to confirm queries still work. Finally, confirm the rollback script works on a copy, so the release can be reversed safely.

Take a backup of a test database with known data, record row counts and a few checksums, then restore it to a separate server. Compare counts, sample records, constraints and users. Measure how long restore takes against the recovery time objective, and check that point-in-time restore loses no more data than the recovery point objective allows. A backup that has never been restored is not proven, so this test should run regularly.

Check how timestamps are stored, ideally in UTC with a time zone aware type. Create a record from a user in IST and another in a different zone, then query the raw value and compare it with what each user sees on screen. Test boundaries such as orders placed just before midnight IST, which fall on the previous UTC date, and daylight saving changes for foreign users. Reports grouped by date are a common bug area.

Test on a database with production-like volume, not a small QA dataset. Measure the run time several times and note the filters used. Ask for or run the execution plan to see whether it does full table scans or uses indexes. Compare with the agreed target, such as under five seconds. Report the query, data volume, timings and plan, and retest after fixes such as indexes, date filters or summary tables.

A memory leak happens when an application keeps holding memory it no longer needs, so usage grows the longer it runs. A manual tester may notice the app getting slower over a long session, a browser tab using more and more memory in Task Manager or the browser's memory panel, or a mobile app crashing after repeatedly opening and closing a screen. Report the steps, duration and memory readings over time.

ARIA, Accessible Rich Internet Applications, is a set of HTML attributes such as role, aria-label, aria-expanded and aria-live that tell assistive technology what a custom component is and what state it is in. The first rule is to prefer native HTML elements, such as a real button, because they are accessible by default. Wrong ARIA is worse than none, so testers verify announced roles and states match real behaviour.

Open the dialog with the keyboard. Focus should move into it, usually to the first field or heading, and the screen reader should announce it as a dialog with its title. Tab must stay inside the dialog while it is open and the page behind must not be reachable. Escape and the close button should close it, and focus must return to the button that opened it. Also check it reads correctly when zoomed.

SUS is a standard ten-question survey that users answer on a five-point agree to disagree scale after using a product. The answers are converted to a score from 0 to 100. A score around 68 is considered average, above about 80 is good and below 50 signals serious usability problems. It is quick and comparable across releases, but it gives a score, not reasons, so teams pair it with observation notes.

First look at what step three asks: maybe address entry, a surprise delivery charge or forced signup. Check analytics for errors, rage clicks and time spent, and watch session recordings if available. Test it yourself on mobile and slow networks. Then run a quick usability test with five users on that step. Present evidence with likely causes and options, such as guest checkout or showing charges earlier, and measure after the change.

Agree on scope: key user journeys and page templates, not every page. Day one, run automated scans on all templates to fix easy issues fast. Then do manual checks of each journey with keyboard, NVDA, VoiceOver on mobile, zoom and contrast. Log issues with WCAG references and severity, and get blockers fixed first. Retest fixes and deliver a conformance summary with known issues. Be honest if full compliance is not realistic.

In India, the Rights of Persons with Disabilities Act 2016 requires accessible information and communication technology, and government sites follow the GIGW guidelines, which align with WCAG. Abroad, the US uses the ADA and Section 508, Europe uses EN 301 549, and the European Accessibility Act applies to many digital products and services from June 2025. Most of these point to WCAG AA as the practical testing target.

WCAG 2.2, published in 2023, added criteria including Focus Not Obscured, so sticky headers must not hide the focused element; Dragging Movements, which needs a non-drag alternative; Target Size Minimum of 24 by 24 CSS pixels; Consistent Help placement; Redundant Entry, so users are not asked for the same information twice; and Accessible Authentication, which avoids memory puzzles at login. It also removed the old Parsing criterion.

Backward compatibility testing checks that a new version still works with older versions of things it depends on or that depend on it. Examples: a new app version opens files and data created by the old one, a new API version still serves older mobile app versions that users have not updated, and an upgraded database keeps old records readable. It prevents breaking existing users when only some parts of the system are upgraded.

Testing is complete when agreed exit criteria are met, not when the bug count is zero. Check that planned tests ran, critical and high bugs are fixed or formally accepted, and remaining open bugs have workarounds and low user impact. Present the list with risk to the product owner, who decides on release. Record accepted bugs as known issues, so nothing is hidden and they are planned for a later release.

Clickjacking tricks a user into clicking something on your site while it is hidden inside a frame on an attacker's page, for example a hidden Transfer button under a fake Play button. A tester checks whether sensitive pages can be loaded in an iframe on another site, and inspects response headers for Content-Security-Policy frame-ancestors or X-Frame-Options set to DENY or SAMEORIGIN. If the page loads in the frame, log it.

Check the CI logs, screenshots, video or trace to see exactly where it failed. Then compare the environments: headless versus headed browser, screen size, browser version, time zone, environment URLs and secrets, test data and network speed. Run the test locally in headless mode with the CI settings. Common causes are timing, missing data in the CI environment and tests depending on run order. Fix the cause, not with a sleep.

Pull request checks must be fast, usually under ten to fifteen minutes, and highly reliable, so they include unit tests, API tests for changed services and a small UI smoke set of critical flows. The full UI regression, cross-browser runs, long data-driven suites and performance checks run nightly or before release. Tag tests by suite, measure run times and flakiness, and move tests between suites based on value and speed.

Compare cost and savings over time. Cost includes building scripts, framework setup, tools, CI infrastructure and ongoing maintenance, often a large share of total effort. Savings include manual execution hours saved per run multiplied by runs per year, earlier bug detection and faster releases. For example, a 40-hour manual regression run every two weeks saves about 1000 hours a year. Tests that run rarely or break often may never pay back.

Do not automate all 500. First clean the suite: remove duplicates and outdated cases. Rank the rest by business risk, run frequency and stability. Start with a smoke set of 20 to 30 critical journeys and move rule-heavy checks to the API level. Choose a tool that fits the team's skills, build a simple framework with page objects and CI runs, then expand in batches while tracking time saved and flakiness.

I agree with the goal of faster and more reliable testing, but explain that 100 percent is neither possible nor useful. Exploratory testing, usability, visual judgement and brand-new features need people, and some flows like real payments or OTP are costly to automate reliably. I would propose clear targets instead, such as automating all critical regression and smoke flows, with metrics like regression time cut from three days to four hours.

Each test should create the data it needs, usually through an API or database helper, use unique values such as an email with a timestamp, and clean up afterwards. Avoid tests that depend on data made by another test or on a shared account other tests change. For fixed reference data, seed it before the suite runs. Independent data allows tests to run in parallel and in any order without random failures.

AI assistants can draft test cases from requirements, suggest edge cases, generate first versions of scripts and test data, and some tools self-heal locators when the page changes. Risks are confident but wrong output, tests that assert the wrong behaviour, hidden locator changes that mask real bugs and leaking confidential data into external tools. Treat AI output like a junior's draft: review it, run it and keep human judgement on what matters.

State the goals, such as cutting regression time and giving pull request feedback within fifteen minutes. Define the split across unit, API and UI layers, the tools and language, which suites run on each pull request, nightly and before release, and who writes and maintains tests. Add entry rules for automating a case, reporting, flaky test handling and environments. Review metrics every quarter and adjust.

Apache JMeter is an open-source load testing tool, mainly for HTTP APIs and web pages. A basic test plan has a Thread Group that sets the number of virtual users, ramp-up time and loop count; samplers such as HTTP Requests; config elements like headers and CSV data; timers for think time; assertions on responses; and listeners or reports showing response times, throughput and errors. Run real load in non-GUI mode.

Situation: our UI scripts broke almost every sprint because of generated IDs and CSS class changes. Task: as the QA lead I needed stable tests. Action: I showed developers the failure history, proposed adding data-testid attributes and accessible labels to key components and added a short checklist to the pull request template. Result: within two sprints locator-related failures dropped by most of the previous level and maintenance time fell sharply.