Question 1

What is the difference between severity and priority?

Accepted Answer

Answer in three sentences — the ideal length for a rapid round. Severity is the bug's technical impact on the system; priority is how soon it must be fixed, which is a business decision. Testers usually set severity, the PO or lead sets priority. Then give two opposite examples — this is what completes the answer: a crash on a rarely used legacy page (high severity, low priority) and a typo in the company name on the homepage (low severity, high priority). For a bonus, add one sentence: "They don't always align — which is exactly why they exist as separate fields."

Question 2

Walk me through the bug lifecycle step by step.

Accepted Answer

List the main path in one breath: New → Assigned → In Progress → Fixed → Ready for retest → Verified → Closed. Then go straight to the alternative statuses — most candidates stop before this, and it's the differentiator: Reopened if the retest fails, Duplicate if already reported, Cannot reproduce, Not a bug for intended behaviour, Deferred if postponed. Finish with a practical nuance: "The bug is normally closed by whoever opened it, after retest. And 'Deferred' must not be forgotten: it needs an owner and a date, otherwise the bug quietly disappears." That nuance signals real experience.

Question 3

What is the difference between positive and negative testing? Give an example.

Accepted Answer

Positive testing — does the system produce the correct result with valid, expected data. Negative testing — does the system fail gracefully with invalid data: no crash, no 500, a clear and useful error message. Pick one field and show both: "On an insurance form the age field accepts 18-65. Positive: I enter 40 — accepted. Negative: empty, 17, 66, -5, 18.5, 'abc', a 200-character string, special characters — and I expect a clear validation message for each." Close with the key sentence: "In practice most bugs are found in negative scenarios, because developers mainly code with the happy path in mind."

Question 4

Black box, white box, grey box testing — which do you do?

Accepted Answer

First separate the three briefly: black box — without knowing the internal code, from inputs and outputs; white box — knowing the code structure, usually developers and unit tests; grey box — with partial internal knowledge. Then answer honestly about yourself — the strongest part of the answer: "Formally a manual QA does black box, but in practice I'm mostly in grey box: I know the DB schema and verify results with SQL, I know the API endpoints and test them directly in Postman, I read the logs. That lets me pin down whether a bug is frontend or backend and greatly improves the quality of my bug reports." This answer shows terminology and real skill together.

Question 5

How do you prepare for a rapid-fire theory round?

Accepted Answer

My preparation has three rules. First — the formula: every answer is 2-3 sentences: the definition, what it gets confused with, one concrete example. Without that structure you either say too little or ramble. Second — practise out loud: I read the questions, answer aloud and time myself. Knowing something in your head and articulating it fluently in 30 seconds are different skills, and only the second one shows in an interview. Third — examples from my own work: I keep one example from my own projects ready for each core concept; a real case instead of a textbook one makes the answer instantly credible. You can add: "If a term comes up that I don't know, I don't invent one — I say so and offer a reasoned guess." That is a signal of honesty in itself.

Question ("difference between X and Y?")	Model answer
Severity vs Priority	Severity is the bug's technical impact on the system; priority is how soon it must be fixed. Testers set severity, the PO/lead sets priority. Example: a crash on a rarely used page is high severity, low priority; a typo in the company name on the homepage is low severity, high priority.
Verification vs Validation	Verification — are we building the product right (conformance to the spec, reviews and static checks). Validation — are we building the right product (does it meet real user needs, dynamic testing and UAT). Example: a requirements review is verification, UAT is validation.
Smoke vs Sanity	Smoke is broad and shallow: does the build work at all, is it worth testing. Sanity is narrow and deep: does a specific change or fix behave sensibly. Smoke decides whether to accept the build; sanity follows a small change.
Re-testing vs Regression	Re-testing verifies a specific bug is fixed, using the same steps. Regression verifies that change didn't break other working areas. Re-testing follows every fix; regression runs before releases and after significant changes.
Black box vs White box vs Grey box	Black box — without knowing the internal code, working from inputs and outputs (the manual QA's main approach). White box — knowing the code structure (usually developers, unit tests). Grey box — with partial internal knowledge: knowing the DB schema, the API or the architecture while testing through the UI — where a manual QA usually actually sits.
Positive vs Negative testing	Positive — does the system produce the expected result with valid data. Negative — does the system fail gracefully with invalid data (a clear error message, not a crash). Example: a valid email in the email field is positive; "user@@mail" or an empty field is negative.
Error vs Defect vs Failure	An error is a human mistake (the developer misreads the spec). A defect/bug is that mistake's result in the code. A failure is the defect manifesting at runtime (the user sees the wrong amount). The chain: error → defect → failure.
Test case vs Test scenario vs Checklist	A test scenario is a high-level statement of what to test ("policy renewal"). A test case is one concrete variant of it, step by step with an expected result. A checklist is a short list of things to check without steps — a lightweight substitute for cases in fast-moving teams.
Alpha vs Beta testing	Alpha — inside the company, in a controlled environment, by internal users. Beta — by real users in their own real environments, before release. Both are forms of acceptance testing.
Load vs Stress testing	Load — does the system hold its required response times under expected normal load. Stress — push it to breaking point to find the limit and see how it breaks (a clean error, or corrupted data).

Single-concept question	Model answer
Walk me through the bug lifecycle	New → Assigned → In Progress → Fixed → Ready for retest → Verified → Closed. Alternative paths: Reopened if the retest fails; Duplicate if already reported; Cannot reproduce; Not a bug if it's intended behaviour; Deferred if postponed. A key nuance: the bug is usually closed by whoever opened it.
The 7 testing principles	Testing shows the presence of defects (not their absence); exhaustive testing is impossible; early testing; defect clustering; the pesticide paradox; testing is context dependent; the absence-of-errors fallacy. In a rapid round, list them all and expand just one with an example.
What is Boundary Value Analysis?	A technique that tests boundary values and both sides of them, because most bugs live at the edges. For a range of 18-65: 17, 18, 19 and 64, 65, 66. It's normally used together with Equivalence Partitioning.
What is a Requirement Traceability Matrix?	A table linking each requirement to the test cases that verify it (and to the defects found). Its purpose: to show no requirement is left untested, and to quickly identify the impact scope when something changes.
What are exit criteria?	Pre-agreed, measurable conditions for calling testing finished: no open Critical/High bugs, ≥95% of planned cases executed, regression passed on critical flows. Their main value is taking "when are we done?" out of the realm of feelings.
What does shift-left mean?	Moving test activities into earlier SDLC phases: QA joins from refinement, reviews requirements and makes sure the AC are verifiable. The reason is simple — a defect found early is many times cheaper.
If a bug reaches production despite testing, whose fault is it?	It isn't a blame question — it's a team outcome. Testing cannot prove the absence of defects (principle 1). The right reaction: assess impact, verify the hotfix, then run a blameless root-cause analysis — why this scenario wasn't in scope and what process change would catch it next time.

Rapid-fire theory questions