QA Engineer Interview Questions
(With Answer Frameworks)

Answer framework

Functional testing verifies that the software does what it is supposed to do — does the login feature accept valid credentials and reject invalid ones? It is behavior-focused and maps directly to requirements. Non-functional testing asks how the software performs those behaviors: how fast does the login page load? Is it secure against SQL injection? Does it handle 10,000 concurrent users? What is the user experience on a mobile screen? Non-functional categories include performance, security, usability, scalability, reliability, and accessibility. A strong QA engineer thinks about both dimensions for every feature — a login page that works but takes 8 seconds is still a bug.

Answer framework

The testing pyramid is a framework for deciding how many tests to write at each level. At the base are unit tests — fast, cheap, and focused on individual functions or components. There should be many of these. In the middle are integration tests — they test how components work together (e.g., an API route plus its database query). At the top are end-to-end tests — they simulate a real user interacting with the full application in a browser. These are the most realistic but also the slowest and most expensive to maintain. The goal is to have most tests at the base. An inverted pyramid (few unit tests, many E2E tests) is an anti-pattern: the test suite becomes slow, flaky, and hard to debug. Good QA engineers push the testing effort down the pyramid wherever possible.

Answer framework

Regression testing is the practice of re-testing previously working functionality after a code change to confirm it still works. Every time a developer fixes a bug or ships a new feature, there is a risk of inadvertently breaking something else — regression tests catch those regressions. Regression suites are usually automated and run as part of a CI/CD pipeline before every release. A well-maintained regression suite gives the team confidence to ship frequently because they know existing functionality will be verified automatically. The challenge is keeping the suite current: tests that cover removed features need to be deleted, and tests for new features need to be added. Maintenance discipline is what separates a useful regression suite from a flaky time sink.

Answer framework

Smoke testing is a shallow, broad check run on a new build to determine whether it is stable enough to proceed with more thorough testing. Think of it as: does the application start? Do the main screens load? Can a user log in? If smoke tests fail, the build goes back to the developer — there is no point running a full test suite on an unstable build. Sanity testing is narrower and deeper: it is a focused check that a specific bug fix or new feature works correctly, typically run after the developer hands off a targeted change. Smoke = broad and shallow (is the house standing?). Sanity = narrow and deep (does the new window actually open and close?).

Answer framework

Positive cases: valid email and password → user is redirected to dashboard; session persists on page refresh. Negative cases: wrong password → error message shown, account not locked on first attempt; empty email field → validation error before submission; invalid email format → inline validation error; SQL injection in password field → no data returned, no error exposed to user. Edge cases: password at maximum allowed length → login succeeds; expired session → redirected to login with a clear message; user with no roles assigned → graceful handling, not a blank screen. Non-functional: page loads in under 2 seconds on a 4G connection; HTTPS enforced — HTTP redirects to HTTPS; password field does not expose input via browser autocomplete inspection. A great answer groups test cases by category and ties each to a risk or requirement rather than just listing them.

Answer framework

When time is limited, use risk-based testing: allocate testing effort proportional to the likelihood and impact of failure. Start with the critical user paths — the features users rely on most to get value from the product (login, checkout, core workflow). Then focus on recently changed code: every change introduces regression risk, and new code has not yet been tested in production. Third, prioritize areas with a history of bugs — if the payment module has had three incidents in the last six months, it deserves more attention than a stable settings page. Also consider release criticality: bugs in a public-facing launch are more costly than bugs in an internal tool. Communicate your prioritization to the team explicitly so stakeholders understand what was and was not tested before release.

Answer framework

Title: 'Submit button on checkout page does not respond to click — order not placed.' Environment: Chrome 124.0.6367.119 on macOS 14.4, staging environment, user account ID #4821. Steps to reproduce: (1) Add any item to cart; (2) Navigate to checkout; (3) Fill in all required fields with valid data; (4) Click the Submit Order button. Expected result: Order is submitted, user is redirected to the order confirmation page. Actual result: Nothing happens. Button does not animate, no network request is made (confirmed via DevTools Network tab), no error message is shown. Severity: Critical — blocks all purchases. Attachments: screen recording showing the click, DevTools console output (no JS errors), network tab screenshot. A great bug report is so complete that a developer can reproduce and diagnose the issue without asking a single follow-up question.

Answer framework

First, make sure your bug report already includes the full reproduction path: exact steps, the specific environment (browser, OS, version), the test account used, and a screen recording or screenshots. If any of these are missing, fill them in immediately. Then reach out to the developer directly — not to argue, but to pair up. Walk through the steps together in real time; 'cannot reproduce' is often 'cannot reproduce in my environment.' Check for environmental differences: is the developer testing on a different browser, OS, or data set? Is the bug specific to a certain user state, locale, or account type? Is it intermittent — does it only happen under certain timing conditions or load? If you still cannot reproduce it together, document the conditions under which you saw it and monitor for recurrence. Some bugs are real but environment-specific or race conditions that surface under certain load patterns.

Answer framework

Selenium is an open-source framework for automating web browser interactions. It allows testers and developers to write scripts that control a browser — clicking buttons, filling in forms, navigating pages — exactly as a human user would. Selenium supports multiple programming languages (Java, Python, JavaScript, C#) and works with all major browsers via browser-specific drivers (ChromeDriver, GeckoDriver for Firefox, etc.). It is most commonly used to automate regression tests for web applications. Selenium WebDriver is the core component; Selenium Grid extends it to run tests in parallel across multiple machines and browsers. For junior QA engineers, knowing how to write a basic Selenium test in Python or JavaScript — locating an element, clicking it, asserting a result — is often enough to stand out. Modern alternatives like Playwright and Cypress have overtaken Selenium for many teams because of better debugging and fewer flakiness issues, but Selenium remains widely used in enterprise environments.

Answer framework

Automate tests that are repetitive, stable, and high-value: regression suites, smoke checks, data-driven tests where the same scenario runs with many input combinations, and any test that runs before every deployment. Automation pays back its creation cost when a test runs frequently enough that the cumulative manual effort exceeds the time to write and maintain the automated version. Keep testing manual when: the test requires human judgment (does this UI look right? Is the UX confusing?), when the feature is exploratory and specifications are still evolving (automated tests on unstable specs need constant rewriting), when the test is truly one-time (running once for a compliance check), or when the UI changes so frequently that the automation cost exceeds the manual cost. A common mistake is automating everything — flaky, expensive-to-maintain tests are worse than no tests. Be selective.

Answer framework

This question tests both your technical judgment and your ability to communicate under pressure. A strong answer names the bug specifically (what was it? what would have happened if it shipped?), shows how you identified it (what were you testing? was this planned or exploratory?), and then focuses on the communication and decision-making. Who did you tell first? How did you frame the severity? What did you recommend — delay, patch, ship with a known limitation? Interviewers want to see that you are not just a bug-finder but a risk communicator. The best answers show that you understood the business context: what was the release deadline for? What would a delay cost? You can find a critical bug and still recommend a measured response if the risk is understood and accepted by the right people. Show that you elevated the decision to the right people rather than making it unilaterally or burying it.

Answer framework

QA and development have a natural tension that becomes destructive if it hardens into an adversarial dynamic. The most effective QA engineers treat quality as shared ownership — not 'I find bugs, they fix them' but 'we both care about shipping something that works.' Practical things that build that relationship: write bug reports that are specific and actionable, never vague or accusatory ('the checkout breaks' vs. 'the Submit button on the checkout page does not fire a network request when clicked after filling in the address form on Chrome 124'); involve developers early — ask questions during spec review or design, not just at the end of the sprint when it is expensive to change; celebrate fixes publicly, not just escalate bugs; and when you find a pattern (the same type of bug appearing repeatedly), bring it up as a systemic question, not a complaint. The best QA engineers make developers trust them — because a developer who trusts their QA partner takes quality seriously rather than seeing QA as an obstacle.