Software Testing Interview Questions for 3 Years Experience
40 questions with answers for candidates with 3 years of experience — 3 easy, 34 medium, 3 hard.
What interviewers expect: 3 years experience
At three years, you are expected to design test approaches for complex features, estimate effort, prioritise by risk and mentor juniors. Interviews dig into integration and end-to-end testing, database validation, API contracts and defect analysis. Basic performance and security awareness and some automation exposure are increasingly expected for QA engineer roles.
This set is weighted towards Agile, SQL and API Testing (6), Test Case Design (5), Performance and Security Basics (5), Manual Testing Basics (5).
Risk-based test planning Complex integration scenarios Defect analysis and metrics Performance and security basics
Solved at this levelStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What is the difference between statement coverage and branch coverage?
Statement coverage measures the percentage of code statements executed by tests. Branch coverage measures whether every decision outcome, true and false, has been executed. Branch coverage is stronger: for 'if (amount > 1000) applyDiscount()', one test with 1500 gives 100 percent statement coverage, but you need a second test with 500 to cover the false branch. 100 percent branch coverage implies 100 percent statement coverage, not the other way round.
02
Your test repository has many duplicate and outdated test cases. How do you clean it up?
Export the cases and group them by module and requirement. Mark duplicates, merge them into one well-written case, and retire cases for removed features. Check which cases have not been executed or failed in months and confirm whether they are still valid. Link the remaining cases to requirements so gaps are visible. Do it module by module with peer review, and set a rule that every story update also updates its test cases.
03
The build arrived three days late but the release date has not moved. How do you prioritise execution?
Rank test cases by business risk and usage: critical flows like login, payment and data saving first, then new features, then high-risk regression from past defects, and cosmetic checks last. Run smoke testing immediately to avoid wasting time on a broken build. Share the reduced plan with the lead and product owner so they know what will not be covered, and get agreement on the remaining risk.
XSS is a vulnerability where an attacker's script is injected into a page and runs in other users' browsers, which can steal session data or change the page. It occurs when user input is shown without proper encoding. Testers enter a harmless script tag or an image tag with an onerror alert in comments, profile names and search boxes, then check if it executes when the page is displayed. Output encoding prevents it.
A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.
A performance baseline is a set of measurements of the current system under a known load, such as response times, throughput, error rate and resource usage. Every new build or release is compared with it to spot regressions. For example, if the checkout API had p95 of 800 milliseconds at 200 users last release and now shows 1.5 seconds, the change needs investigation. A benchmark compares against an industry or competitor standard.
07
A developer changed a shared header component used on every page. What testing do you plan?
Retest the change itself, then run a focused regression on every page type that uses the header: home, listing, detail, checkout and account. Check navigation links, search, login and logout state, cart count and the mobile menu. Do cross-browser and responsive checks because layout changes affect all sizes. A quick visual comparison against the previous build helps spot alignment issues across many pages.
08
Difference between black box, white box and grey box testing?
Scalability testing checks how well the system handles growing load by adding resources, such as more servers or bigger machines, and whether performance improves in proportion. For example, if two servers handle 1,000 users, do four servers handle about 2,000 at the same response time? It finds limits that resources cannot fix, such as a single database bottleneck, and helps plan capacity for future growth.
11
Write a JQL query for open high or highest priority bugs in the current sprint of project PAY.
project = PAY
AND issuetype = Bug
AND statusCategory != Done
AND priority in (Highest, High)
AND sprint in openSprints()
ORDER BY priority DESC, created ASC
12
Write test cases for a coupon code field at checkout.
Apply a valid coupon and check the discount and final amount. Test invalid, expired and not-yet-active coupons. Check minimum order value, maximum discount cap and category restrictions. Verify one-time-use coupons cannot be reused and that only one coupon applies if stacking is not allowed. Check case sensitivity and leading or trailing spaces. Remove the coupon and confirm the total resets. Change cart items after applying and verify the discount is recalculated.
13
What is the difference between a walkthrough and an inspection?
Both are static review techniques. A walkthrough is informal and led by the author, who explains the document or code to peers to share knowledge and gather feedback. An inspection is the most formal review: it has defined roles such as moderator, reader and scribe, uses checklists, needs preparation and records defects and metrics. Inspections find more defects but take more effort.
14
Tell me about a time you pushed for an accessibility fix the team wanted to postpone.
Situation: before a release, I found the payment form errors were not announced by screen readers and not reachable by keyboard. Task: the team wanted to defer it. Action: I recorded a short NVDA video showing a user could not finish payment, linked it to WCAG and our customer commitments, and proposed a small fix. Result: the fix took half a day, shipped in the release and we added keyboard checks to our definition of done.
Verify reset with a registered email sends a link. Verify an unregistered email shows a generic message without revealing whether the account exists. Check the link opens the reset page and expires after the defined time. Check the link works only once. Validate new password rules and that confirm password must match. Verify login works with the new password and fails with the old one. Check resend limits and that other sessions are logged out.
A latent defect exists in the software but has not caused a failure yet because the needed conditions have not occurred, such as a leap-year bug that appears only on 29 February. A masked defect is hidden by another defect, for example a broken discount calculation you cannot reach because the cart page crashes first. After the first bug is fixed, the masked one appears, which is one reason regression and retesting matter.
Test enabling biometrics in app settings after a password login. Verify login with a registered fingerprint or face, and failure with an unregistered one, falling back to PIN or password after the allowed attempts. Remove or add a fingerprint in device settings and check the app asks for re-authentication. Test devices without biometric hardware, disabled biometrics and app behaviour after an OS update or reinstall.
Think time is the pause a real user takes between actions, such as reading a product page before adding it to the cart. Performance scripts add think time, often with random variation, so virtual users behave realistically. Without think time, a few virtual users generate a load equal to many real users, which gives misleading results. Think time values are usually taken from analytics or production logs.
21
During a load test, some booking requests fail with a 'deadlock detected' error. What is happening and how do you report it?
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.
Situation: a small tax rounding change was made late on a Friday. Task: no manual regression was planned for pricing. Action: our nightly API suite failed one data-driven case where a 3-item cart was off by one rupee; I checked the trace, reproduced it manually and logged it with the failing input. Result: it was fixed before release, and the team agreed to keep pricing tests in the pull request suite.
24
What is cold start versus warm start, and why test app launch time?
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.
Shift-left means starting testing activities earlier in the life cycle: reviewing requirements, joining design discussions and writing tests before code is complete. A defect found in requirements may cost a short conversation to fix, while the same defect found in production may need a hotfix, data correction and customer support. Testers shift left by asking questions in grooming, defining acceptance criteria and reviewing designs.
26
You change the order ID in a URL and see another customer's order. What is this and what do you do?
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.
27
How do you test location-based features in a mobile app?
Test with location permission allowed, denied and approximate only. Use mock location tools to simulate different cities and moving routes. Verify the app shows nearby results correctly, updates location while moving and handles GPS turned off. Check accuracy indoors and with weak GPS, battery impact of continuous tracking and that background location is used only if needed and explained to the user.
28
A user updates their phone number in the app, but the old number still appears in reports. What do you check?
First query the main users table to see whether the update was saved. If it was, check where the report reads from: a view, a reporting copy, a cache or a nightly ETL table. The report may simply be stale until the next refresh, which may be by design. If the main table still has the old value, check the API request, the update query and any errors in logs, then log a bug with both query results.
Create your own data with a clear prefix or tag, such as emails starting with qa_ravi_, or IDs in a reserved range. Insert data through the app or API where possible so it follows real rules, and keep SQL setup scripts in version control. After testing, delete only your tagged rows, or run inside a transaction and roll back. Never edit shared master data without telling the team.
31
Product is running an A/B test on the checkout button. What does QA need to verify?
QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.
32
What is a sprint planning meeting and what does QA contribute?
Define goals and three to five realistic tasks, such as 'Book a train ticket for next Friday'. Recruit participants who match real users. In the session, explain that you are testing the product, not them, ask them to think aloud, and avoid hinting even when they struggle. Record the screen with consent, note where they hesitate or fail, and finish with a short questionnaire. Then group findings by severity and frequency.
36
Managers say the automation test report is hard to understand. What should a useful report include?
A useful report shows total tests run, passed, failed and skipped, the run time, the environment, build number and browser. For each failure it should show the test name, the failing step, the error message, and a screenshot, video or trace, plus logs. Trends across runs help spot flaky tests. Linking failures to Jira bugs or manual case IDs helps managers see real product risk, not just numbers.
Recovery testing checks how well the system recovers from crashes, hardware failures, network loss or other failures. For example, kill the server during a file upload, or disconnect the network during payment, and verify the system restores a consistent state, does not lose or duplicate data and resumes or shows a clear message. It also measures recovery time against agreed targets, which matters for banking and healthcare systems.
38
What automated accessibility tools exist and what are their limits?
Common tools are axe DevTools, Lighthouse in Chrome, WAVE and accessibility linters in CI. They quickly catch missing alt text, low contrast, missing labels and invalid ARIA. Their limit is that they find only roughly a third of WCAG issues. They cannot judge whether alt text is meaningful, focus order is logical, error messages make sense or a custom widget works with a screen reader, so manual testing is still required.
39
Write test cases for live order tracking in a food delivery app.
Verify each status change appears in order: placed, accepted, preparing, picked up and delivered. Check the rider's location updates on the map at the expected interval. Test the estimated time updates when there is a delay. Verify notifications for each status. Check behaviour when the network drops and recovers, when the app is reopened, and when the order is cancelled midway. Confirm tracking stops after delivery and the rating screen appears.
The extent of requirements or code exercised by tests. Measure requirement coverage with a traceability matrix and code coverage with tools.
Frequently asked questions
What is asked in Software Testing interviews for 3 years of experience?
At three years, you are expected to design test approaches for complex features, estimate effort, prioritise by risk and mentor juniors. Interviews dig into integration and end-to-end testing, database validation, API contracts and defect analysis. Basic performance and security awareness and some automation exposure are increasingly expected for QA engineer roles.
How many questions should I practise before a Software Testing interview?
Work through all 40 questions here, then the company-wise sets for the employers you are targeting. Quality matters more than count: be able to explain why each answer is right.
Which topics matter most for 3 years of experience?
Focus first on Risk-based test planning, Complex integration scenarios, Defect analysis and metrics, Performance and security basics.