Become a QA engineer · Part 2
Test Design & Strategy.
Part 1 gave you the mental model. This is the craft. It is the part of the job I love most: taking a vague requirement and turning it into a plan, a set of cases, and the confidence that you have covered what matters. You cannot test everything, so the whole skill is choosing well. I will show you how I do it, the same way I taught it in my bootcamp, and it is free.
This is part of a 4-part path:Part 1 Become a QA Engineer,Part 2 Test Design & Strategy (you are here),Part 3 How QA Fits Into Any System,Part 4 Test Execution & Defect Management.
Prefer to watch and click through?
The slide lesson
The whole course as an illustrated, interactive deck: think like a tester, set the direction, write cases people can run, cover more with fewer cases, then prioritise, trace and design with AI. Five sections, with a knowledge check, flashcards and fill-in-the-blanks at the end.
New here? Start with Part 1
Become a QA Engineer
This course assumes you know the foundations: the SDLC, test types and levels, severity vs priority, and how testers think. If any of that is hazy, do Part 1 first. It is free and it takes a few hours.
The path
From a requirement to a tested product, in order
Eight modules that follow the real flow of the work: understand, plan, design, then prioritise. Tick each one off as you go, and your progress saves in this browser.
Think like a tester before you write a thing
Good test design starts in your head, not in a template. Before any case gets written, you decide who you are testing for and how hard you are willing to push.
- The tester mindset: curious, organised, focused, and a relentless communicator
- The four users you design for: the perfect, the mindless, the extreme and the malicious
- Read the requirements until you are the expert, then ask the questions that fill the gaps
Most defects are decided before a single test case exists. This is where you catch them.
Turn requirements into testable expectations
In agile, requirements arrive as user stories and acceptance criteria, and they are rarely complete. Your job is to make them clear enough to test against.
- Reading user stories and acceptance criteria the way a tester reads them
- What to actually do when the requirements are thin or contradictory
- The role you play in refinement: ask questions early, before code is written
Vague requirements are where quality quietly dies. A tester in the room changes the outcome.
Test strategy vs test plan: the documents that set direction
A strategy is the team’s general approach to testing across projects. A plan is how one project or release gets tested. The plan expires with the release. The strategy is what every plan is built from.
- Test strategy: scope, approach, environments, tools, release control, risk and approvals
- Test plan: overview, resources, estimation, schedule, approach and risk for one project
- The agile reality: the one-page plan and the test charter, not a 40-page document nobody reads
Once you can hold these two apart, every planning conversation gets easier. You will build a real, shareable plan.
Estimate and schedule testing without guessing
Estimation is not a dark art. It is a few honest techniques and the discipline to schedule around dependencies, priorities and the milestones that cannot move.
- Three estimation approaches: analogy, expert judgement and task breakdown
- Scheduling around dependencies, what to test first, and what runs in parallel
- The honest challenges: being added late, and answering “how much testing is enough?”
Get this wrong and you either delay the release or ship something low quality. Both are on you.
Write test cases people can actually run
A test case is a set of conditions someone who has never seen the app can follow to decide pass or fail. Write them so a stranger could run them, because one day a stranger will.
- The six characteristics: accurate, economical, traceable, repeatable, reusable and atomic
- A template that holds up: id, title, steps, expected and actual results, status, priority, test data, preconditions and platform
- Positive and negative cases, and writing them in Gherkin (Given, When, Then)
Your test cases are the most visible thing you produce. They get read, reused and shared.
Cover more with fewer cases: test design techniques
Exhaustive testing is impossible, so you test smart. These techniques let a small set of cases cover a huge space of behaviour, and they are exactly what interviews probe.
- Equivalence partitioning and boundary value analysis, used together
- Decision tables for combinations of rules, and state-transition testing for flows
- Pairwise (combinatorial) testing when the input space explodes
A handful of well-chosen cases beats a thousand random ones. This is the craft, not luck.
Find the cases the requirements never mention
The bugs that hurt most are the ones nobody specified. Heuristics and structured exploration help you find the behaviour, the edge and the misuse that no acceptance criterion wrote down.
- Identifying cases from behaviours, user roles, workflows and what the app should NOT do
- Heuristics and mnemonics: RCRCRC for regression, I SLICED UP FUN for mobile
- Exploratory testing as structured curiosity, run as time-boxed, charter-led sessions
Requirements describe the happy path. Real users, and real attackers, do not stay on it.
Prioritise, trace, and design tests with AI
You will always have more cases than time. Prioritise by risk, prove your coverage with traceability, and let AI draft the first pass so your judgement goes where it counts.
- Risk-based prioritisation: P1 to P4, and Must, Should, Can, Meh
- Traceability: mapping every requirement to the cases that prove it
- Designing with AI honestly: draft Gherkin, expand boundary and equivalence sets, and a first-pass plan from a story, then you review, correct and own it
AI drafts the obvious cases fast. Choosing what matters, and judging the risk, is still you.
Practice & play
Design is a doing skill
You will not learn boundary values or strategy-vs-plan by reading them once. Test yourself, because that is how the techniques actually stick.
Knowledge check
Score 0 / 71What is the key difference between a test strategy and a test plan?
A test strategy sets the general approach across the organisation. A test plan applies it to one specific project, with its own scope, schedule and resources.
2A username field accepts 6 to 15 characters. Which set best reflects boundary value analysis?
BVA tests the edges and one step past them: just below the minimum (5), the minimum (6), the maximum (15) and just above it (16). That is where defects cluster.
3Which technique is the right first reach when output depends on a combination of several conditions?
Decision tables lay out combinations of input conditions and their expected actions, so you cover the rules without missing a combination.
4You have far more candidate cases than time allows. What is the professional move?
Risk-based prioritisation puts the cases that protect core functionality and high-impact areas first. P1 must run; lower priorities run as time allows.
5In Gherkin, what does the “Given” step describe?
Given sets the context (the precondition), When is the action, and Then is the expected outcome. It keeps cases readable and unambiguous.
6Why use equivalence partitioning and boundary value analysis together?
Boundaries tell you the edges behave; partitions tell you the range behaves. Used together you know both, and you know which one broke.
7What is the honest, safe way to use AI when designing test cases?
AI is leverage for the first draft: expanding boundary sets, drafting Gherkin, sketching a plan from a story. The judgement, the risk call and the final coverage are still yours.
Flashcards (tap to flip)
Known 0 / 14A high-level, organisation-wide document defining the general approach to testing.
A project-specific document: the scope, approach, resources and schedule for testing one thing.
The conditions a story must meet to be considered done. Your cases trace back to these.
Grouping inputs the system should treat the same, then testing one value per group.
Testing the edges of an input range: min, max, and one step either side, where bugs cluster.
A grid of input conditions and their resulting actions, used to cover combinations of rules.
Designing cases around the states a system moves through and the events that move it.
Covering every pair of input values instead of every combination, to keep cases manageable.
Validates the app does what it should using valid input. The happy path.
Validates the app handles invalid input or illogical steps gracefully.
A Given-When-Then format for writing test cases in plain, structured language.
A map linking each requirement to the test cases that prove it, so coverage is provable.
Simultaneously learning, designing and running tests. Structured curiosity, not random clicking.
A short mission for a time-boxed exploratory session: what to explore and why.
Match the term to its meaning
0 / 6 matchedClick a term, then click its meaning. Get all six to clear the round.
Fill in the missing word
Go further
Where to deepen this
Start with mine. After that, here is an honest shortlist for going deeper on test design.
From me
Trusted elsewhere
When your cases are solid
Part 4: run the cycle and drive every defect to closed
Designing the cases is half the job. Next you run them against a real build, report what fails, and manage each defect through to closed. That is Part 4, and it is the natural next step on this path.
Stuck on a technique?
Test design clicks with practice and a second pair of eyes. Reach out on LinkedIn, or send me a message and tell me which technique is not landing yet.
Field Notes
Build better products
by testing what matters.
Get practical notes on testing, automation, AI, mobile apps, and release decisions. I share the workflows, lessons, tools, and mistakes from real product work so you can ship with more confidence and fewer last-minute surprises.