Test Planning
Testing without a plan is like building a house without a blueprint - you might end up with walls and a roof, but the doors won't open. This topic covers the logistical and strategic backbone of the testing process: scope, schedules, estimation, and the models that keep it all balanced.
~12 min read
The core ideas, explained
The Test Plan
A Test Plan outlines the activities, resources, schedule, and risks for testing. In sequential (Waterfall) models, it's often a massive, formal document created upfront. In Agile models, Test Planning is continuous and dynamic, often documented in release or sprint plans instead. Its key contents are Scope (what is in and out), objectives, budget, environments, roles, and risk mitigation strategies.
In scope: the crypto processing API and UI. Out of scope: credit card processing, which was tested last year and hasn't changed. Risk: the third-party crypto API might be slow. Mitigation: plan for performance testing in week 2.
Entry Criteria and Exit Criteria
These are the strict "gates" that control the flow of testing. Entry Criteria answer "when can we start?" - the conditions that must be met before a specific testing activity can begin. Exit Criteria answer "when are we done?" - the conditions that must be met to declare testing finished. In Agile, Exit Criteria are heavily tied to the Definition of Done.
You cannot start System Testing unless the code has been compiled, unit tests have passed, and the test environment is fully configured. If the server is down, you fail the entry criteria.
Exit criteria dictate that 100% of critical-risk tests must pass, and 0 critical defects can remain open. If a critical bug is still open on Friday afternoon, you cannot release the software.
Estimation Techniques
Management always asks "how long will testing take?" - you can't just guess. Metrics-Based Estimation uses historical data and mathematical formulas from past projects to estimate the current one. Expert-Based Estimation asks the people doing the work to use their experience to estimate the effort, often via Planning Poker.
Last sprint, it took the team 10 hours to write tests for 50 lines of code. This sprint has 100 lines of code, so you mathematically estimate it will take 20 hours.
The team sits together. The Product Owner reads a user story. Each tester throws down a card with a number representing effort. If Tester A plays a "2" and Tester B plays an "8," they discuss why their estimates differ until they reach a consensus.
Test Case Prioritization
You rarely have time to run every test case, so you must prioritize them so the most important tests are already completed if time runs out. Risk-Based Prioritization tests the things most likely to fail and cause the most damage first. Coverage-Based Prioritization prioritizes tests that execute the highest amount of un-executed code or requirements. Requirements-Based Prioritization tests the features business stakeholders care about most, first.
Test the checkout payment logic before testing the footer CSS - a bug in payment costs far more than a misaligned footer link.
The Test Pyramid
The Test Pyramid is a model, popularized by Mike Cohn, showing how a healthy test suite should be structured based on granularity and execution speed. The bottom level (Unit Tests) is the base - thousands of fast, cheap, highly isolated tests written by developers. The middle level (Integration/API Tests) is slower and more complex, checking how components talk to each other. The top level (UI/System Tests) is the tip - very few, slow, brittle, and expensive tests simulating a real user clicking through the interface. The anti-pattern, the Ice Cream Cone, is when a team writes zero unit tests and relies entirely on hundreds of slow, manual UI tests - the pyramid is inverted, and testing becomes a massive bottleneck.
A healthy team has 1,000 unit tests running in 30 seconds, 100 integration tests running in 5 minutes, and 10 UI tests running in 20 minutes. An Ice Cream Cone team instead has 5 unit tests and 300 manual UI test scripts that take two full days to run through by hand.
The Testing Quadrants
The Testing Quadrants are a model, by Brian Marick, used to categorize different types of testing in Agile, divided by two axes: Business-facing vs. Technology-facing, and Guiding Development vs. Critiquing the Product. Quadrant 1 (Tech-facing, Guides Dev) covers unit and component testing, automated. Quadrant 2 (Business-facing, Guides Dev) covers functional testing, ATDD, and BDD scenarios. Quadrant 3 (Business-facing, Critiques Product) covers exploratory testing, UAT, and usability testing, manual. Quadrant 4 (Tech-facing, Critiques Product) covers performance, security, and load testing with automated tools.
A team writes Given/When/Then scenarios before coding a checkout feature, to guide the developers on exactly what to build. That's Quadrant 2 - Business-facing, and Guiding Development, since it's written before the code exists.
Key points to remember
- Entry/Exit: Entry = "ready to start." Exit = "Definition of Done."
- Metrics = data; Expert = people. Use metrics when you have historical data; use experts (Planning Poker) when requirements are novel.
- Test Pyramid: lots of unit tests at the bottom, very few UI tests at the top - fast at the bottom, slow at the top.
- Testing Quadrants: the left side (Q1/Q2) guides the building of the software; the right side (Q3/Q4) critiques the software after it's built.
- Prioritization: always execute the highest risk tests first.
Terminology
A few terms from this topic worth knowing precisely.
Defining test objectives and the approach to reach them within a project's constraints - scope, risks, resources, schedule, and entry/exit criteria.
The conditions that must be met before a specific testing activity can begin - e.g. code is compiled, unit tests passed, and the test environment is ready.
The conditions that must be met to declare a testing activity or project officially complete - e.g. 100% of critical-risk tests passed and zero critical defects remain open.
The shared, agreed checklist a User Story or increment must satisfy to be considered complete - in Agile, Exit Criteria are heavily tied to this.
Using historical data and mathematical formulas from past projects to estimate the effort a current project will require.
Asking the people who will do the work to use their own experience and judgment to estimate the effort required - Planning Poker is a common technique for this.
An Expert-based estimation technique where team members independently reveal effort estimates for a story, then discuss and reconcile any large differences until they reach consensus.
A model showing a healthy test suite should have a broad base of fast, cheap Unit tests, a smaller middle layer of Integration/API tests, and a tiny tip of slow, expensive UI/System tests.
An inverted, unhealthy test suite that relies mostly on slow, fragile, manual UI tests with very few unit tests underneath - the opposite of the Test Pyramid, and a major maintenance bottleneck.
A model categorizing Agile test types across two axes - Business-facing vs. Technology-facing, and Guiding Development vs. Critiquing the Product - into four quadrants.
Summary
Test planning brings order to chaos. It defines the scope, sets strict entry and exit criteria, estimates effort using data or expert consensus, and prioritizes work based on risk. Modern Agile teams rely on models like the Test Pyramid (to avoid over-investing in slow UI tests) and Testing Quadrants (to ensure they're testing both technology and business requirements from all angles).
| Concept | One-line memory hook |
|---|---|
| Test Plan | The master blueprint of scope, schedule, risks, and resources |
| Entry Criteria | The prerequisites to begin testing |
| Exit Criteria | The prerequisites to stop testing |
| Planning Poker | An expert-based estimation technique to build team consensus |
| Test Pyramid | Broad base of fast Unit tests; tiny peak of slow UI tests |
| Testing Quadrants | 4 boxes categorizing tests (Business vs. Tech / Guide vs. Critique) |
Check your understanding
20 questions, easy to hard - click an option to see if you got it right.