1.9Living Test Plans: Keeping Documentation Current
A test plan that is accurate on day 1 and outdated by day 10 provides no value. Here are strategies for keeping plans current.
Co-Locate with the Work
Store the test plan where the team works. If the team uses Jira, link the plan from the epic or sprint. If the team uses GitHub, put it in the repository. If the plan is in a wiki that nobody visits, it will rot.
Make Updates Part of the Workflow
- Update the plan when sprint scope changes
- Update the risk section when a risk materializes or a new one is identified
- Update the exit criteria when the team agrees to a scope change
- Review the plan briefly in sprint retrospective: "Was the plan accurate? What should we change for next sprint?"
Automated Freshness Checks
For teams with many test plans, use automated reminders:
- Set a review date on every document
- Use a bot or calendar reminder to ping the owner when a plan has not been updated in 30 days
- Archive plans for completed projects so they do not clutter the active workspace
PRO TIP: The best test plan is the shortest one that still aligns the team. If you can achieve alignment with a Jira ticket description and a checklist, you do not need a separate document. The format matters far less than the content. A test plan in a Slack message that everyone reads is more valuable than a Confluence page that nobody opens.
COMMON MISTAKE: Writing the test plan after testing is complete "for documentation purposes." If the plan did not guide the testing, it is fiction. Write the plan before or at the start of testing, when it can actually influence decisions.
Exercises: Chapter 1
Beginner:
- Exercise 1: Take your team's most recent test plan (or find one online). Evaluate it against the "why test plans go unread" table. List three specific improvements you would make. (Writing Exercise 1)
- Exercise 2: Write a one-page sprint test plan for a login feature that includes: email/password login, social login (Google, Apple), forgot password flow, and two-factor authentication. Use the one-page template from this chapter. (Writing Exercise 2)
Intermediate: 3. Exercise 3: Compare the IEEE 829 structure to the one-page template. Which IEEE 829 sections would add value to your team's current test plans? Which would be overkill? Write a brief justification for each decision. (Writing Exercise 3) 4. Exercise 4: Write a release test plan (2-3 pages) for a major release that includes three new features, five bug fixes, and a database migration. Include a regression strategy, compatibility matrix, and rollback criteria. (Writing Exercise 4)
Advanced: 5. Exercise 5: Create a test strategy document for a product you know well that covers the next 6 months. Address all five key questions (what, what not, how, risks, done criteria) and include a section on how individual sprint test plans should reference the strategy. (Writing Exercise 5) 6. Exercise 6: Establish a plan review process for your team. Define: who reviews, when they review, what the sign-off mechanism is, and how changes are managed. Write this up as a one-page process document. (Writing Exercise 6)