Question 1

The code isn't ready yet — what do you work on?

Accepted Answer

This question tests proactivity, so answer with a concrete list: (1) I review the requirements and acceptance criteria and turn the unclear parts into a question list for the PO/BA; (2) I write test cases and checklists and plan UI scenarios from the design mockups; (3) I prepare test data (e.g. customer profiles across ages and tenure) and check the test environment; (4) I define the regression scope for the areas this feature touches; (5) I refresh stale test cases. Close by stressing that a defect found at this stage is the cheapest defect there is.

Question 2

How do you decide whether a requirement is testable?

Accepted Answer

My check is simple: "can I write a test case for this requirement whose result is unambiguously pass or fail?" If I can't, it isn't testable. In practice I run through the criteria: unambiguity, measurability (is there a number and a unit?), completeness (is the error path described?), consistency, traceability. Give an example: "'The payment should be processed quickly' isn't testable — 'payment confirmation is shown within 5 seconds in 95% of cases' is." The example is what stops this answer from sounding theoretical.

Question 3

What is the difference between a walkthrough and an inspection?

Accepted Answer

The difference is formality and purpose. In a walkthrough the author leads the team through the document; the goal is shared understanding and collecting questions — no defined roles or metrics. An inspection is a formal process: moderator, author, reviewer and scribe roles, material distributed in advance, checklist-driven preparation, a formal defect list, entry/exit criteria and metrics. Add a practical note: "Full inspections are rare in Agile teams — we run refinement like a walkthrough and add a lightweight review checklist on top." That ties the theory to a real process.

Question 4

How do you raise an issue found in a review so it isn't taken as criticism?

Accepted Answer

I have three rules. First, critique the document, not the person: not "you wrote it wrong" but "this sentence can be read two ways". Second, raise it as a question: "Is renewal allowed on the expiry day itself?" That lets the author think without going defensive. Third, show the impact: "if we don't settle this, two different behaviours could be implemented and the renewal flow breaks". Finally I record the agreed answer in the ticket — a verbal agreement is gone in a week. This answer demonstrates both technical and communication maturity.

Review type	Formality	How it runs	Output
Informal review	Lowest	A quick "take a look at this" with a colleague — no paperwork	Verbal notes, small corrections
Walkthrough	Low-medium	The author walks the team through the document step by step, questions are raised	Shared understanding, a list of open questions
Technical review	Medium	Technical experts evaluate the proposed solution	A technical decision and alternatives
Inspection	Highest	Defined roles (moderator, author, reviewer, scribe), checklists, metrics	A formal defect list, entry/exit criteria

Static testing & requirement review