QA interview questions and answers (the essentials)

Verification asks "are we building the product right?" and validation asks "are we building the right product?". Verification is checking against the spec and documents through reviews and walkthroughs, before or without running the code. Validation is actually running the software to confirm it meets the real user need. For example, verification confirms the login screen matches the design document; validation confirms a real user can actually log in and reach their dashboard.

QA, quality assurance, is process-focused and preventive: it improves the way we work so fewer bugs happen in the first place. QC, quality control, is product-focused and detective: it checks the actual product for defects. Testing is one activity inside QC where you run the software to find those defects. The way I put it: QA improves the recipe and the kitchen, QC inspects the cake, and testing is the act of tasting it.

An error is the human mistake a developer makes in the code. That mistake becomes a defect, or bug, in the product. A failure is what the user actually sees when that defect runs and the software behaves wrongly. So the chain is: error leads to defect, and a defect that gets triggered causes a failure. In day-to-day talk, most teams use bug and defect interchangeably.

Severity is how badly the bug hurts the system; priority is how soon it needs to be fixed. Severity is usually set by QA, priority is set by the business or product owner. They do not always move together. A typo in the company name on the homepage is low severity but high priority because it is embarrassing and visible. A crash in a rarely used admin report is high severity but low priority because almost no one hits it.

Smoke testing is a quick, broad check that the build is stable enough to test at all. It hits the major features like login, search, and checkout, before we invest time in deeper testing. Sanity testing is narrow and deep: after a small fix or change, you confirm that specific area works, plus a few related things. I think of smoke as "is the whole build alive?" and sanity as "did this one fix actually work without breaking its neighbours?".

Retesting is checking that a specific bug is actually fixed: you run the exact steps that failed before and confirm they now pass. Regression testing is checking that the fix or new change did not break anything that used to work. Retesting is planned and uses known failing cases; regression is broader and often automated. For example, after a fix to the discount code, retesting confirms the code now applies, and regression confirms the cart total, taxes, and checkout still work.

Black box testing checks behaviour from the outside without looking at the code: you give inputs and verify outputs against the requirement. White box testing looks inside the code and tests the logic, branches, and paths, so you need programming knowledge. Grey box is a mix, where you know a little about the internals, like the database structure. As a manual tester I mostly do black box, but knowing white box helps me write smarter cases and talk to developers.

Functional testing checks what the system does against the requirements, like "can I add an item to the cart and check out?". Non-functional testing checks how well it does it: performance, security, usability, accessibility, and compatibility. For example, functional testing confirms search returns the right results; non-functional confirms search returns them within two seconds under heavy load. Both matter, because a feature can pass functionally but still fail by being too slow or insecure.

Positive testing feeds valid input and confirms the system does what it should, the happy path. Negative testing feeds invalid or unexpected input and confirms the system handles it gracefully instead of crashing. On a sign-up form, positive testing is entering a valid email and a strong password and registering successfully. Negative testing is entering a malformed email, a blank password, or pasting 1000 characters, and checking for clear, polite error messages.

Both are techniques to test smartly without trying every possible input. Equivalence partitioning groups inputs that should behave the same way, so you test one value from each group instead of all of them. Boundary value analysis focuses on the edges of those groups, because that is where bugs hide. For an age field that accepts 18 to 60, equivalence partitioning tests one invalid-low, one valid, and one invalid-high value; boundary analysis tests 17, 18, 60, and 61 specifically.

STLC is the set of phases QA goes through for any testing effort. The phases are requirement analysis, test planning, test case design, test environment setup, test execution, and test closure. Each phase has entry and exit criteria, so you know when you are ready to move on. It runs alongside the SDLC but focuses purely on the testing activities, and it keeps testing organised instead of just clicking around randomly.

The bug life cycle is the journey of a defect from the moment it is found to the moment it is closed. A typical flow is New, then Assigned, then Open, then Fixed, then Retest, then Closed. Along the way a bug can also be marked Rejected, Duplicate, Deferred, or Not a Bug, and it can be Reopened if the fix did not work. As a tester I log it as New, the lead assigns it, the developer fixes it, I retest, and I close it only when it genuinely passes.

The SDLC, software development life cycle, covers the whole process of building software, from requirements through design, coding, testing, deployment, and maintenance. The STLC is the testing-specific slice of that, focused only on the QA phases. Testing is one stage inside the SDLC, but the STLC zooms in and breaks that stage into its own detailed phases. In short, the STLC lives inside the SDLC.

In Waterfall, testing is a distinct phase that happens after development is complete, so QA gets involved late. In Agile, testing is continuous and happens every sprint, with QA involved from day one, sitting in standups and refinement. Agile favours fast feedback, smaller batches, and a lot of regression and automation. Most teams today are Agile or a hybrid, so I am comfortable testing features as they land rather than waiting for a big handoff.

Shift-left means moving testing earlier in the development process instead of leaving it to the end. QA joins requirement reviews, asks questions before code is written, and helps catch ambiguity and edge cases up front. The idea is that a bug caught in a requirement discussion is far cheaper to fix than one caught in production. In practice, shift-left is me reviewing acceptance criteria and writing test cases before the developer even starts coding.

You never test everything, so you stop based on agreed criteria, not on running out of bugs. Common signals are: all planned test cases executed, the exit criteria in the test plan met, the critical and high bugs fixed, the defect-find rate dropped off, and the deadline reached. I also weigh risk: if the remaining open bugs are low severity and low priority, the build can ship. The honest answer is that testing is about confidence and risk, not perfection.

A test scenario is a high-level idea of what to test, like "verify the login functionality". A test case is the detailed, step-by-step version of that, with preconditions, exact steps, test data, and the expected result. One scenario usually breaks into many test cases. For login, the scenario is "test login", and the test cases are valid login, wrong password, blank fields, locked account, and so on.

A good test case has a clear ID and title, any preconditions, the test data, the exact steps, and the expected result, plus a field for the actual result and pass or fail status. The key is that anyone on the team should be able to run it and get the same outcome without asking me questions. I keep the steps atomic and specific, so "enter a valid email" becomes "enter user@test.com in the email field". Clear test cases are reusable and survive after I leave the project.

A traceability matrix, or RTM, is a table that maps each requirement to the test cases that cover it. Its job is to prove coverage: every requirement should have at least one test case, and you can quickly spot any requirement with none. It also works in reverse, helping you find orphan test cases that do not map to any requirement. When a requirement changes, the RTM instantly tells me which tests I need to update.

A test strategy is a high-level, often organisation-wide document that sets the overall approach, standards, and tools for testing. A test plan is project-specific and detailed: scope, objectives, schedule, resources, environments, entry and exit criteria, and risks. The strategy rarely changes; the plan is written per release. In a small team they sometimes merge into one document, but the distinction is that strategy is the philosophy and the plan is the concrete how-to for this project.

Exploratory testing is simultaneous learning, test design, and execution, where you actively explore the app and let what you find guide your next move, rather than following a fixed script. It is great when documentation is thin, time is short, or you want the bugs that scripted cases miss. I usually timebox it into sessions with a charter, like "explore the checkout flow for 45 minutes", and take notes so it stays accountable. It complements scripted testing rather than replacing it.

Ad-hoc testing is informal testing with no plan, no documentation, and no test cases. You just use the application and try to break it based on your experience and intuition. It is useful for a quick gut check or to find bugs in a hurry, but it is hard to reproduce and not repeatable. The difference from exploratory testing is that exploratory is structured and documented with charters, while ad-hoc is truly off the cuff.

When I find a bug, I first reproduce it to confirm it is real and to nail down the exact steps. Then I log it in the tracker, usually JIRA, with a clear title, steps to reproduce, expected versus actual result, severity and priority, the environment, and a screenshot or screen recording. I check it is not a duplicate before raising it. A rule I follow: write the report so a developer can reproduce the bug without ever talking to me.

A good title is specific and tells the reader the what, where, and impact at a glance. Instead of "Login broken", I write "Login fails with valid credentials when email has uppercase letters". A developer should be able to triage and roughly understand the issue from the title alone, before opening the ticket. Vague titles cause duplicate reports and slow triage, so I treat the title as the most important field.

I stay factual and not defensive. I share the exact steps, the environment details like browser, OS, and build version, and a screen recording so the difference is obvious. Often the gap is an environment or data difference, so I walk through it together to find what is different. If it is genuinely not reproducible after that, I am happy to mark it accordingly, because the goal is the right product, not winning the argument.

I prioritise by risk and impact. First I cover the critical user paths and the highest-traffic or highest-revenue flows, like login, checkout, and payment. Then I focus on whatever changed in this release, since new and modified code is where bugs cluster. I lean on smoke and high-priority regression cases, and I am transparent with the team about what I am consciously not covering, so it is an informed decision rather than a silent gap.

First I ask. I go to the product owner, business analyst, or developer and clarify the intended behaviour, because guessing wastes everyone's time. While I wait, I test against what is documented, plus common sense and similar past features, and I note my assumptions in the test cases. I also rely on standards a user would expect, like clear error messages and reasonable validation. Raising the ambiguity early is itself valuable, because a missing requirement is a defect too.

Developers test that their code works, which is the happy path, but testers think about how it could fail, which is a different mindset. A second, independent set of eyes catches assumptions the author cannot see, and QA looks across features for integration and regression issues a single developer would miss. There is also a cost argument: a bug caught before release is far cheaper than one a customer finds in production. Independent testing buys confidence, not just bug counts.