Reviews
Review types and the analyst's role
Reviews are static testing: they find defects in work products before execution. ISTQB defines four types, increasing in formality: informal (no process), walkthrough (author leads, aims at learning and consensus), technical review (documented, technically qualified peers, led by a moderator, finds and discusses defects) and inspection (most formal, defined roles, entry/exit criteria, metrics and follow-up). Only inspection is truly "formal" in the sense of a complete documented process.
The standard process is planning, kick-off, individual preparation, review meeting, rework and follow-up. Roles include manager (decides and allocates), moderator (leads), author, scribe/recorder and reviewers. The test analyst is often a reviewer of the test basis - requirements, user stories, designs - looking for testability, verifiability, consistency, completeness and ambiguity, and may serve as scribe or moderator.
Review techniques include ad hoc, checklist-based, scenario-based and perspective-based reading (each reviewer adopts a stakeholder viewpoint). Traps: calling a walkthrough a formal inspection; thinking reviews find failures (they find defects, not runtime failures); assuming the author cannot be a reviewer or that the moderator is the manager; and forgetting that follow-up is part of the process.
Worked example. Reviewing a login requirement with a checklist, the analyst raises: "the lockout threshold after failed attempts is not specified" (ambiguity) and "no acceptance criterion for password reset" (untestable). Both are logged as defects against the requirement.
Rule of thumb: choose the review type by risk and formality needs, and always record who does what and whether exit criteria were met.