Learner can describe a realistic end-to-end QA workflow and run a small test session, reporting the defects they find.
The end-to-end QA workflow
From requirements to release: the full QA cycle
A QA engineer does not simply click around and hope to find bugs. The work follows a repeatable workflow that keeps testing systematic and traceable.
Step 1 — Understand requirements: read the specification, acceptance criteria, or user story. Clarify ambiguities before writing a single test case.
Step 2 — Write a checklist or test cases: decide what to check. Use techniques from earlier in this course — equivalence classes, boundary values, and decision tables — to choose inputs. Write both positive cases (valid input, expected success) and negative cases (invalid input, expected error).
Step 3 — Execute tests: run each case, record the actual result, and note pass or fail. Keep notes; do not rely on memory.
Step 4 — Log defects: for every failure, write a clear bug report with title, environment, steps to reproduce, expected result, actual result, severity, and priority. Severity reflects technical impact (owned by QA); priority reflects business urgency (owned by product).
Step 5 — Retest and regression: once a fix is deployed, re-run the failed cases. Also run a regression pass on related areas to make sure the fix did not break anything else.
Step 6 — Report: summarise the test session — how many cases ran, how many passed, defects found, open blockers. This gives stakeholders an objective view of quality before release.
This cycle repeats for every feature and every sprint. Knowing where you are in the cycle at any moment is what separates a professional tester from a casual clicker.
Lesson notes
From requirements to release: the full QA cycle
A QA engineer does not simply click around and hope to find bugs. The work follows a repeatable workflow that keeps testing systematic and traceable.
Step 1 — Understand requirements: read the specification, acceptance criteria, or user story. Clarify ambiguities before writing a single test case.
Step 2 — Write a checklist or test cases: decide what to check. Use techniques from earlier in this course — equivalence classes, boundary values, and decision tables — to choose inputs. Write both positive cases (valid input, expected success) and negative cases (invalid input, expected error).
Step 3 — Execute tests: run each case, record the actual result, and note pass or fail. Keep notes; do not rely on memory.
Step 4 — Log defects: for every failure, write a clear bug report with title, environment, steps to reproduce, expected result, actual result, severity, and priority. Severity reflects technical impact (owned by QA); priority reflects business urgency (owned by product).
Step 5 — Retest and regression: once a fix is deployed, re-run the failed cases. Also run a regression pass on related areas to make sure the fix did not break anything else.
Step 6 — Report: summarise the test session — how many cases ran, how many passed, defects found, open blockers. This gives stakeholders an objective view of quality before release.
This cycle repeats for every feature and every sprint. Knowing where you are in the cycle at any moment is what separates a professional tester from a casual clicker.