Test strategy for a real project

You cannot test everything. A coffee shop's ordering API has endless possible inputs, and a team has a limited number of days. A test strategy is the set of decisions about *what* to test, *how deeply*, *with which kinds of tests*, *where they run* and *who is responsible*. It turns "we should test more" into a plan.

Think of a doctor with a limited time: they don't run every test on every patient. They look at the symptoms, the risks and the cost, then choose. Testing works the same way.

Risk = how likely something is to go wrong, times how bad it would be. Spend your effort where both are high.

For Brew & Bean, a wrong total on an order means customers are overcharged or the shop loses money: high impact, and pricing code changes often. A typo in the "About us" page is low impact. So pricing gets deep testing, and the About page gets a quick look.

Each kind of test answers a different question (see *Why we test: the test pyramid and types of testing*). Use the cheapest test that can catch the bug.

A common mistake is the ice-cream cone: many slow, fragile browser tests and few unit tests. It looks thorough but is slow, flaky and hard to debug. Aim for a pyramid or a honeycomb (heavier on API and integration tests, common for services): most checks run below the browser, and the browser covers only a handful of critical journeys such as "browse the menu, place an order, see it as received".

A strategy also says when testing starts and when it is "done enough". Write these as short rules everyone can check.

Many test failures are not code bugs but data or environment problems. Decide in advance:

- Environments: local (developer), CI (clean, automatic), staging (like production, shared) and production (monitor only, no destructive tests). - Test data: create it inside the test (a factory like make_order), so each test is independent. Avoid depending on a shared record that someone may delete. - Secrets and personal data: use fake phone numbers and names. Never copy real customer data into a test environment. - Third parties: mock or use a sandbox for payment providers and SMS gateways, so tests are fast and free (see *Mocks, stubs and test doubles*).

A good bug report lets a developer reproduce the issue in two minutes: a clear title, steps, expected and actual result, environment, and evidence (response body, screenshot, log). Include severity (how bad the effect is) and let the product owner set priority (how soon to fix).

Measure things that drive decisions, and be careful with numbers that can be gamed. Useful: time for CI to give feedback, number of flaky tests, bugs found in production versus before release, how long a bug takes to fix. Misleading on its own: the raw count of test cases, or 100% code coverage. Coverage tells you which lines ran, not whether anything was checked.

Write the strategy so it fits on one page. A page that gets read beats a 40-page document that doesn't. Here is a template, shown as a prompt you can reuse with an AI tool, and then a short example.

You are a senior QA lead. Draft a one-page test strategy for the project below. Use these headings: Scope (in and out), Top 5 risks, Test types and what each covers, Automation approach and tools, Environments and test data, CI pipeline, Entry and exit criteria, Roles, Open questions.

Project: [what it is, users, tech stack]
Team: [size, skills]
Release frequency: [weekly / monthly]
Biggest worry: [e.g. wrong prices, downtime, data leaks]

Keep it under 400 words and use plain English. Mark anything you assumed with (assumption).

What to expect: Check that the risks match your real worries, that every test type has a reason to be there, and that exit criteria are measurable. Delete anything generic.

Brew & Bean ordering API: test strategy (summary)

Scope: GET /menu, POST /orders, GET /orders/{id}, PATCH /orders/{id}/status.
Out of scope: payments (not built yet), the admin dashboard.

Top risks: 1) wrong order totals, 2) invalid status jumps, 3) bad input
crashing the API, 4) slow responses at the 8 am rush, 5) customer phone
numbers exposed.

Tests: pytest unit tests for pricing; pytest API tests for every endpoint
(positive, negative, boundary); integration tests against Postgres; one
Playwright journey (browse, order, see status); k6 smoke test on every
deploy and a load test weekly; ZAP baseline scan weekly.

Pipeline: unit + API tests on every pull request (target under 3 minutes);
integration and e2e after those pass; load and security on a schedule.

Exit criteria for a release: all critical journeys green, no open
critical/high bugs, p95 response time under the agreed limit, ZAP scan has
no high findings.

Roles: developers write unit and API tests with their code; the QA engineer
owns the framework, exploratory sessions and the release checklist.

A short, specific strategy. Notice it names real endpoints and real risks, instead of generic sentences.

Interviewers for QA and SDET roles often ask: "How would you test this feature?" or "How would you design an automation framework?" Good answers follow the structure above: clarify the requirement, list risks, pick test types by cost and value, say what you would automate and what you would test by hand, and mention data, environments and CI.

Also expect "What would you not automate?" Good answers: one-off checks, tests of rapidly changing screens, and exploratory testing, where human curiosity finds what scripts can't.