The test plan nobody reads
A forty page test plan is a document written to be approved, not used. The version that gets read fits on one screen and changes every sprint.
Somewhere in most companies there is a test plan. It was written once, approved by three people, and has not been opened since. It describes a product that has changed twice, and it is the reason teams believe planning does not help.
The document is not the problem. The length is.
Written to be approved, not used
A long test plan optimises for the wrong reader. It is built to survive a review meeting, so it carries a glossary, a scope statement, a risk register, and four pages about the tools.
None of that is read by the person doing the testing on Tuesday. They need to know what to check and in what order, and they need it to be current.
If it cannot be read in the time it takes to make coffee, it will be read once.
What actually belongs in it
Four things. Everything else is either obvious, already in the ticket, or stale within a month.
- The flows in priority order, with the top three marked as the ones that block a release.
- What is out of scope this cycle, written down, so silence is not mistaken for coverage.
- The environments and data you need to do the work, including which account to use.
- The risks you already know about, meaning the areas that broke before.
That fits on one screen. It also means an update takes two minutes, which is the only reason it will ever get one.
Keep it next to the work
The plan should live where the tickets live, not in a documents folder nobody browses. If the team works in issues, it is an issue. If the team works in a wiki, it is one page in the wiki with the sprint number in the title.
A plan in a separate system is a plan that drifts, because updating it is a context switch and nobody makes one for a document they do not believe in.
Rewrite it, do not amend it
Every cycle, delete and rewrite. It takes ten minutes when it is one screen long, and it forces someone to ask what changed. Amending a long document preserves everything that is no longer true, which is how a plan gets to forty pages in the first place.
The test of a good plan is boring: two months from now, can someone new to the team read it and know what to check first? Ours are one page for that reason.