Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2016 (3 hours, open book, 8 questions of equal value; the first FIVE as they appear in the answer book are marked — all eight are solved here as a study resource).
Case 1 — medium-size waterfall company (100 employees). A dedicated SQA group/function, separate from the development team producing the work product, typically organizes and conducts the FTR as a distinct project milestone at the end of each linear phase (requirements review, design review, code inspection). The review has a formal moderator (often from SQA or a peer team, not the author's own manager), a designated recorder, and a fixed roster of reviewers drawn from development, SQA and sometimes the customer — the scale of the organization supports specialized, independent review roles.
Case 2 — small agile team (5 developers). There is no separate SQA department to draw reviewers from, so the FTR is conducted by the development team itself, peer-to-peer — commonly as pair programming (continuous, informal review as code is written) and/or a short end-of-sprint code review / sprint review meeting where a rotating team member acts as moderator. The whole team effectively shares the SQA role, and reviews happen far more frequently (daily/per-story) but each one is lighter-weight than the waterfall case's formal milestone review.
Part (b) — scheduling the SQA review in agile. Under agile, quality review cannot wait for large phase-end milestones (there aren't any) — it has to be embedded inside the short (1-2 week) sprint cadence itself:
Continuously, during development — pair programming and mandatory peer code review on every pull request/commit, so defects are caught within hours, not weeks.
At the story/task level — each user story carries its own "definition of done" that includes a review step before the story can be marked complete, rather than reviewing the whole increment at once.
At the sprint review/demo — the end-of-sprint ceremony doubles as a lightweight FTR of the working increment against the sprint's acceptance criteria, with the Product Owner and team present.
At the sprint retrospective — a process-level (not product-level) review of how well the SQA activities themselves worked that sprint, feeding process improvement into the next sprint.
Automated continuously — static analysis, linting and the automated test suite run on every commit (continuous integration), acting as an always-on, machine-executed layer of the SQA review that a small team could not staff manually at that frequency.
