Review and Next Steps

You have produced a non-functional test plan. Now evaluate it.

A QA lead reviewing a junior engineer's plan would ask the same questions every time. This lesson gives you those questions as a self-assessment checklist, walks through the most common gaps in first-attempt plans, and maps what to study next based on which area you want to deepen.

Self-assessment checklist

Work through this checklist against the plan you wrote. Be honest — the value of this review depends on it.

Scope and framing

• Does every section begin with an explicit scope statement that names what is in and out of scope?
• Does the plan acknowledge what is not tested before launch (mobile app performance, GDPR pen test if not delivered in time) and frame these as documented risks rather than omissions?
• Does the executive summary convey the risk profile without requiring the reader to read the full document?

Acceptance criteria

• Does every section have measurable acceptance criteria — numbers, not qualitative statements?
• Are the acceptance criteria traceable to a business requirement, not chosen arbitrarily? (e.g., the p95 target is derived from conversion rate research; the WCAG requirement is derived from legal obligation)
• Could someone who did not write the plan use the acceptance criteria alone to make a go/no-go decision?

Tools and environment

• Is every tool named specifically — not "a performance testing tool" but "k6 with k6 Cloud"?
• Does each section specify which environment the test runs against?
• Are environment dependencies (production-equivalent staging, seeded database) identified with an owner and a date they are needed?

Scheduling

• Is every test type mapped to a month and — where it matters — a specific week?
• Does the schedule front-load what can run early (SAST, axe-core in CI, smoke compatibility) and defer what requires the full staging environment to Month 2?
• Does the Month 3 plan leave enough time for remediation after the Month 2 findings come in?

Risk section

• Is each major risk in the plan identified — pen test timing dependency, mobile app handover timing, staging environment readiness, database seeding?
• Does each identified risk have a stated mitigation or a fallback (e.g., if pen test staging is not ready, defer by one week and compress Month 3 sign-off)?

Cross-area integration

• Does the performance soak test also serve as a reliability monitoring exercise (not just a performance test)?
• Does the accessibility plan address mobile screens specifically (not just the web app)?
• Is the i18n Year 1 scope clearly distinguished from the Year 2 localisation scope so the reader understands what changes post-launch?

Common gaps in first-attempt plans

Gap 1: Acceptance criteria that are not measurable. "Performance should be good" and "no major accessibility issues" appear in plans more often than they should. These statements cannot drive a go/no-go decision. If your criteria section contains adjectives without numbers, it is not finished.

Gap 2: Testing scheduled against an environment that will not be ready. Many plans schedule load testing in Month 1 before establishing that the staging environment is not production-equivalent until Month 2. The test cannot run as designed because the dependency has not been validated. Read your own schedule once with the question: "What does this test require to run, and is that thing available at the scheduled time?"

Gap 3: Security treated as a single event. A pen test in Month 2 is not a security testing programme — it is one event in one. Plans that stop at "we will commission a pen test" have not addressed what happens before the pen testers arrive (SAST, dependency scanning, ZAP DAST), or what happens after (retesting remediated findings).

Gap 4: Localisation conflated with translation. Year 1 plans that propose commissioning German translations when no i18n infrastructure exists have the order wrong. Translation is useless without externalised strings. i18n foundation is the Year 1 work; translation is Year 2. If your plan proposes translation before pseudo-localisation has been run, revisit the ordering.

Gap 5: Mobile treated as an afterthought. A plan that comprehensively covers the web application and mentions "we will also test the mobile apps" at the end has not planned mobile testing — it has noted that mobile testing exists. Mobile requires specific tools (Appium or native instruments), specific devices (or a cloud device farm), specific screen reader testing (VoiceOver on iOS, TalkBack on Android), and the same type of journey-based coverage as the web app.

Stretch goals for stronger plans

If your plan covers the baseline checklist above, consider these additions:

Monitoring-as-testing. Define what CloudWatch alarms and dashboards should exist and what they measure. A test plan that does not address how failures will be detected in production is incomplete — passing a load test in staging is not the same as knowing that a production performance regression will be caught and alerted on.

Feature flag strategy for non-functional risk. If a new payment flow or a significant frontend change is launched behind a feature flag, the test plan should note that performance and security testing covers the flag-off and flag-on states separately.

Third-party SLA verification. ShopRight depends on Stripe for payments, CloudFront for CDN, and AWS for infrastructure. The plan notes that Stripe's sandbox has rate limits — but a stronger plan also documents the Stripe and AWS SLAs and notes that ShopRight's own SLAs cannot exceed what its dependencies guarantee.

Post-launch monitoring schedule. A non-functional test plan ideally extends into the first 30 days post-launch with a monitoring cadence: weekly review of error rate trends, p95 response time in production (via Grafana/CloudWatch), and first-month synthetic monitoring runs to verify critical journeys are passing continuously.

Where to go next

This course has been deliberately broad. Every chapter identified where the topic gets deeper, and pointed to more specialised courses. The map below shows which deep-dive courses address which areas of the ShopRight plan.

The choice of what to study next depends on what you found hardest in this capstone. If writing the performance acceptance criteria felt uncertain, start with the k6 course — it covers how to derive thresholds from data rather than guessing. If the security plan felt thin, the OWASP ZAP course builds hands-on scanning skills. If mobile testing felt like a gap, the Appium course covers device farm integration and gesture automation in depth.

What this capstone demonstrates

A completed ShopRight plan, checked against the self-assessment above, demonstrates a specific set of capabilities:

• Breadth of coverage — you can identify non-functional risk across seven distinct areas simultaneously, not just the one or two areas most familiar to you.
• Constraint-aware thinking — you can adapt a test plan to a fixed timeline, limited environment availability, and a team that does not include dedicated security or performance specialists.
• Communication across functions — the plan is written for an audience that includes engineers, a DevOps engineer, product managers, and potentially legal or compliance stakeholders. Each section gives enough context that a non-QA reader understands what is being tested and why.
• Measurable outcomes — every section has acceptance criteria that can drive a real go/no-go decision.

These are the capabilities that distinguish a QA engineer who tests features from a QA engineer who shapes the quality of a product. The ShopRight scenario is a simulation, but the skills it exercises are the same ones applied to real products, real deadlines, and real business risk.

⚠️ Common mistakes

• Submitting the walkthrough as your plan. The walkthrough is one possible approach — it is not a template to copy. A plan produced by copy-pasting the walkthrough and changing "ShopRight" to your product name demonstrates that you followed instructions, not that you understood the thinking. Write your own scope boundaries, your own acceptance criteria, your own tool rationale.
• Treating every area as equally important. A plan that gives equal depth to all eight areas when the business risk is heavily concentrated in two or three areas has not exercised prioritisation judgement. The plan should reflect where the most risk is — and explain why.
• Writing a plan for a perfect world. Real plans must survive contact with delayed environments, agency handovers that slip, and engineers who have other priorities. A plan that only works if everything goes right is fragile. Build in the "what if the staging environment is not ready" fallback; document the "what we will not test before launch and why" explicitly.

The ShopRight plan is the output of this course. It is also a portfolio artifact: a document that demonstrates non-functional testing thinking to a technical lead, a QA manager, or a hiring team. The skills you have exercised here — planning under constraints, selecting tools for specific contexts, writing measurable acceptance criteria — are the same skills you will use on the first real project that needs a non-functional test strategy.