Test Planning
Fail to plan, plan to fail. A Test Plan is the contract between the test team and the project: what will be tested, how, by whom, and with what success criteria.
1 The Hook — The "Blind" Project
Imagine building a bridge. You have the steel, the workers, and the tools. But nobody knows which side to start from, who is in charge of the concrete, or what happens if it rains. You'll end up with a pile of metal in the river. In software, testing without a plan is just random clicking.
A Test Plan ensures everyone knows the Goal, the Timeline, and the Definition of Done. If it's not in the plan, it's not being tested.
2 The Rule — Scope, Strategy, Sign-off
A professional Test Plan must define Scope (In/Out), Entry/Exit Criteria, and Risks.
- Scope: What are we testing (and what are we NOT testing)?
- Criteria: When are we allowed to start, and when are we allowed to stop?
- Resources: Who is doing the work, and what tools do they need?
3 The Analogy — The Battle Plan
The General vs. The Soldiers.
The **General** (Test Lead) writes the **Battle Plan** (Test Plan). It shows the big picture: where the enemy is, where the supply lines are, and what "Victory" looks like. The **Soldiers** (Testers) don't need to know every detail of the supply chain; they just need their specific **Mission Orders** (Test Cases) for the day. But without the General's plan, the Soldiers will fight the wrong battle. The Test Plan is the General's map of the project.
4 Watch Me Do It — NZ Bank App Plan
Scenario: You're the Lead for a new NZ Mobile Banking App. You need to follow the IEEE 829 standard (lightweight).
- Define Scope: IN: App Login, Transfers, Balance. OUT: Credit Card apps (separate project).
- Set Entry Criteria: "Code is merged to Staging, and Unit Tests pass at 80%."
- Identify Risks: "Bank API might be slow during month-end." Mitigation: Run performance tests early.
- Define Exit Criteria: "100% of P1/P2 bugs fixed. 95% pass rate. Sign-off from Product Owner."
- Resource Check: "We need 2 Senior Testers and access to the ASB Test Environment."
5 Decision Tool — Strategy vs. Plan
📙 Test Strategy (The Standard)
- Scope: Whole Company.
- Lifespan: Years.
- Answers: "How do we test as a company?" (e.g. We use Postman).
📋 Test Plan (The Mission)
- Scope: One Project.
- Lifespan: Weeks/Months.
- Answers: "How do we test this specific feature?"
6 Common Mistakes
🚫 Skipping Exit Criteria
I used to think: We'll stop testing when we run out of time.
Actually: Testing ends for one of two bad reasons: time or money. Without **Exit Criteria**, you'll be forced to sign off a broken app because the deadline arrived. Define the "Safety Standard" upfront.
🚫 Not listing "Out of Scope"
I used to think: Everyone knows we aren't testing the legacy app.
Actually: If it's not written down as **OUT**, stakeholders will assume you're doing it. Explicitly listing what you WON'T test is the best way to prevent "Scope Creep."
7 Now You Try — Fill in the Plan
Scenario: You're planning a 2-week sprint for a "Password Reset" feature.
Which of these is a valid Entry Criterion?
Entry criteria are things that must happen **BEFORE** testing starts.
8 Self-Check
Q1. What is the difference between a Test Plan and a Test Schedule?
The **Test Plan** is the "What and How" (Scope, Strategy, Risks). The **Test Schedule** is the "When" (Dates, Milestones). A schedule is usually *part* of a plan.
Q2. What are "Suspension Criteria"?
These are conditions where you **Stop** testing. For example: "If the login page is broken, stop all testing because we can't reach the rest of the app." This prevents wasting time on a broken build.
9 Interview Prep
"How do you handle a change in scope mid-way through a project?"
Answer: "I immediately update the Test Plan and the Risk Register. I inform the stakeholders that the new scope requires more time or more resources. If neither is available, we must agree to cut something else from the scope. I never just 'absorb' the extra work, as it compromises the quality of the exit criteria."
10 Next Step
You've got the map. Now, let's decide where to attack first. Next: Risk-Based Testing.