Review and Self-Assessment Checklist

You have completed the capstone. Before celebrating, this final lesson takes you through a structured review of the work you produced, a set of reflection questions to surface what you learned and where the gaps still are, and a roadmap for what to study next. Treat the checklist as a sparring partner — be honest, mark what is weak, and use the result to guide the next phase of your learning.

Self-assessment checklist

Open the eight folders you produced in the previous lesson and grade each artefact on the questions below. A strong rating is for work you would be comfortable showing a hiring manager; adequate is functional but with rough edges; needs work means you have identified a clear gap to fix.

Risk assessment

• ❑ Did you identify at least three high-risk areas, with explicit reasoning that combines likelihood and impact?
• ❑ Did you also identify the low-risk areas — and use that to free up time for the high-risk ones?
• ❑ Could a stakeholder read the assessment in two minutes and understand where the team will spend most of its testing effort?

Test plan

• ❑ Does it have all five sections from chapter 2 — scope, approach, schedule, risks with mitigations, entry/exit criteria?
• ❑ Did you state what is out of scope as clearly as what is in scope?
• ❑ Are the entry and exit criteria checkable — could two reasonable people agree on whether each one is met?
• ❑ Is the whole document one page or less?

Test cases

• ❑ Did you write at least 20 cases, with a healthy mix of positive, negative, and edge cases (roughly 40/40/20)?
• ❑ Could a tester on day three of their job execute each case without asking you a question?
• ❑ Are the expected results specific enough that "did this pass?" has an unambiguous answer?
• ❑ Did you include at least one accessibility-focused case (e.g., the screen-reader booking flow)?

Exploratory testing

• ❑ Did you write a clear charter — mission, target areas, time-box?
• ❑ Did you keep a log during the session, not just at the end?
• ❑ Did the session find at least one issue that the structured cases would not have caught?
• ❑ Did you debrief honestly: what did you not get to, what is worth a follow-up?

Bug reports

• ❑ Does each report use the seven-field template — title, environment, steps, expected, actual, screenshot/video, severity/priority?
• ❑ Could a developer reproduce the bug on the first attempt, without follow-up questions?
• ❑ Are titles scannable in a queue of 30 tickets, naming the area, the symptom, and the environment?
• ❑ Did you score severity and priority separately with a one-line justification each?

Test summary report

• ❑ Does the executive summary answer "is this releasable?" in 30 seconds?
• ❑ Have you included at least one chart or visual?
• ❑ Did you name the residual risks honestly, not just the wins?
• ❑ Could a non-technical PM use this report to make a real release decision?

If any of these checks come back needs work, that is the highest-leverage next thing for you to improve. Fix it now while the context is fresh.

Reflection questions

Write a short answer (3–4 sentences each) to the following before moving on:

• What was the hardest part of the capstone? Most testers find one of the six deliverables disproportionately harder than the others. Identifying which one tells you where to invest your next round of practice.
• Which areas did you feel most confident about? The areas you found easy are often the techniques you should teach others, which is the fastest way to deepen your own mastery.
• What would you do differently with more time? This question separates competent work from senior work. Senior testers always have a list of "next sprint I would also do X" — they understand explicitly what they did not test, and why.
• How would your testing change if you had automation available? The honest answer is that the manual-only and automation-aware approaches differ less than people expect. Automation moves the boring repetitive parts off your plate so you can spend more time on the work in this capstone — exploratory, accessibility, edge cases. The capstone you just produced is the work that survives when automation arrives.

Save the answers in 08_SignOff/reflection.md. They will be useful to you a year from now when you look back at the work.

Where to go from here

You have built one of the strongest foundations a manual tester can have. From here, three different specialisations are worth exploring depending on your interests:

A few concrete starting points already on qa.codes:

• Automation. Start with JavaScript for testers and TypeScript for testers. Then learn one framework deeply rather than three superficially — Cypress commands, Playwright commands, and the Cypress / Playwright tool pages.
• API testing. Start with HTTP status codes, then Postman API testing. Cucumber/Gherkin and REST Assured cover contract testing afterwards.
• Accessibility. The accessibility testing cheat sheet extends chapter 5; after that, deeper WCAG 2.2 work and screen-reader fluency on JAWS and NVDA.
• Performance. k6, JMeter, and Grafana / InfluxDB for QA are the entry points; performance has its own thinking around percentiles, SLOs, and capacity planning.
• Security. OWASP top-10 awareness, then hands-on with Burp Suite or OWASP ZAP plus a structured threat-modelling habit.

The other course on qa.codes — Software testing fundamentals — remains the foundation under all of the above. Beyond that, the path depends on what kind of work you want to do next.

You finished. Be proud of it.

You have produced a portfolio of artefacts that an experienced manual tester would recognise as serious work. You have a risk assessment, a defended test plan, twenty deterministic test cases, an exploratory session log, five well-formed bug reports, and a stakeholder-ready summary report. You can defend each of those to a hiring manager or a release stakeholder.

That is not a small thing. Most testers reach this capability in their first year on the job, often through trial and error with little guidance. You have done it as a structured course in considerably less time. Save the folder somewhere you will not lose it; share it with the next interviewer who asks "show me a piece of testing work you have done end to end." It is your answer.

Whatever you do next — automation, deeper API work, accessibility, performance, security — the foundations from this course will travel with you. Manual testing is not a stepping stone you leave behind once you learn automation; it is the discipline that makes every other kind of testing more effective. The skills you have practised across these eight chapters are exactly the skills that compound over a career.

Welcome to the craft. Now go and find some bugs.