Project Brief — Non-Functional Test Plan for a Web Application

You have covered seven areas of non-functional testing: performance, security, accessibility, usability, cross-browser and cross-device compatibility, localisation, and reliability. Now you will apply all of them together. This capstone asks you to design a comprehensive non-functional test plan for a realistic product — not to implement it, but to plan it with the rigour a QA lead would bring to a real project.

A test plan that covers only functional behaviour is incomplete. ShopRight is your test subject.

The ShopRight scenario

ShopRight is a UK-based furniture and home goods retailer preparing to launch a new e-commerce platform. The product replaces a legacy system and has a hard launch date three months from now.

Product scope:

• Web application (React frontend, Node.js API, PostgreSQL database, hosted on AWS)
• iOS native app
• Android native app
• 100,000 product catalogue with filtering, search, and product comparison
• User accounts, saved wishlists, order tracking
• Checkout with card payments (Stripe integration for PCI compliance)
• Guest checkout without account creation

Scale targets:

• Current: 10,000 daily active users
• Peak (sales events, Black Friday): 50,000 concurrent sessions
• Expected growth: 3× within 18 months of launch

Localisation roadmap:

• Year 1: English (en-GB) only
• Year 2: French (fr-FR), German (de-DE), Spanish (es-ES)

Regulatory and compliance requirements:

• PCI DSS compliance for payment card data (handled via Stripe Elements — card data never touches ShopRight servers)
• WCAG 2.1 Level AA (UK Equality Act 2010 obligation)
• GDPR data handling (consent flows, cookie banner, data deletion)

Infrastructure:

• Three AWS availability zones in eu-west-1 (Ireland)
• RTO: 30 minutes | RPO: 15 minutes
• Database: Amazon RDS PostgreSQL with Multi-AZ enabled
• CDN: CloudFront for static assets

The eight plan deliverables

Your non-functional test plan must address eight areas. Each area requires a section that answers the same four questions: what you are testing, how you are testing it, what tools you need, and what the acceptance criteria are.

Constraints you must work within

A test plan that ignores constraints is not a plan — it is a wish list. ShopRight has real constraints that shape what is feasible.

Time: Three months to launch. Month 1 is early integration testing; Month 2 is full staging environment available; Month 3 is pre-launch hardening and sign-off.

Environment: A production-equivalent staging environment becomes available at the start of Month 2. Month 1 testing must work against partial integrations.

Team: One QA lead (you), one QA engineer joining in Month 2, one DevOps engineer available two days per week for infrastructure-level testing support.

Budget signals: The business has approved a BrowserStack Automate subscription. External penetration testing has budget allocated. k6 Cloud is approved for load testing — no self-hosted load infrastructure is needed.

Risk register (from the product team):

• Black Friday is 6 weeks post-launch — the first real peak load event
• The mobile apps are being built by a third-party agency; handover is in Month 2
• The legacy database migration carries data integrity risk

What a strong plan looks like

Strong plans share common traits regardless of the product being tested:

Specificity over generality. "We will test performance" is not a plan. "We will run a k6 load test simulating 50,000 virtual users with a 5-minute ramp-up on the product listing, product detail, and checkout flows, with p95 response time acceptance criteria of 2 seconds for page loads and 3 seconds for checkout submission" is a plan.

Acceptance criteria per area. Every non-functional area needs a defined pass/fail threshold, not just a list of things to check. The threshold should be derived from business requirements — not chosen arbitrarily. "Performance passes" means nothing. "p95 response time under 2 seconds at 50K concurrent users, error rate below 0.1%, and no memory growth exceeding 200MB over a 4-hour soak" means something.

Tool and environment specificity. Name the tools. Specify which environment. Note any dependencies — if load testing requires a production-equivalent database with realistic data volume, that is a dependency that must be resolved before the test can run.

Risk-informed prioritisation. Not everything can be tested at equal depth. The plan should reflect where risk is highest. For ShopRight: payment flows carry regulatory and financial risk; checkout performance under peak load is a direct revenue risk; WCAG compliance is a legal obligation. These areas warrant deeper coverage than, say, usability heuristic evaluation of the admin panel.

Integration with the delivery schedule. Tests that cannot be run until two days before launch are not part of the plan — they are a hope. Each test type should be mapped to when in the three-month timeline it runs, what environment it needs, and what the output is.

The deliverable format

Your capstone plan should be structured as a document with eight sections — one per area from the ConceptMap above — plus an executive summary and a schedule section.

For each area section, write:

1. Scope — what is in scope for this area, and what is explicitly out of scope.
2. Test approach — the specific types of tests you will run (load test, pen test, accessibility audit, etc.) and why those types address the risk.
3. Tools and environment — what you need and where it runs.
4. Acceptance criteria — the specific, measurable thresholds that define pass/fail for this area.
5. Risks and dependencies — what could prevent this test from running, or what could make the results unreliable.

This format forces completeness. If you cannot fill in acceptance criteria, you have not finished planning — you have only finished listing.

Before you start

The next two lessons walk through a worked example of this plan, covering all eight areas. Read them before completing your own plan — the walkthrough shows how the constraints above shape specific decisions, and how each area connects to the others.

The final lesson in this chapter asks you to review your plan against a self-assessment checklist and identify what you would do differently given more time, budget, or headcount.

This is a design task. The output is a test plan document. The measure of success is not whether the plan is executable in a real ShopRight project — it is whether the plan demonstrates that you can apply non-functional testing thinking across all seven areas simultaneously, reason about trade-offs under real constraints, and communicate a strategy clearly enough that a development team or product manager could understand and act on it.