The Test Plan Nobody Reads

For over a year I sent a test plan at the start of every sprint. Same format, same sections, shared in the same Slack channel every time. In all that time, maybe one or two of them got a comment from anyone outside the QA team. Not from product. Not from engineering. I kept sending them anyway, convinced that if I just got the format right, or shared it at the right time, people would eventually engage.

They didn’t. And at some point I had to stop pretending the document was the problem.

Nobody Wants to See the Risks

Most fast-moving teams actually care about shipping quality software. It makes everyone look good. So it’s not that they’re against test planning in principle. It’s that risk conversations feel like a trap. If you flag something and it ships broken anyway, you were there, you saw it coming, and it still happened. If you never engage with the risk document, you’re clean. Silence is just the safer bet.

A test plan surfaces risks — things that could go wrong, gaps in what’s being tested, tradeoffs the team is accepting. That’s exactly the kind of conversation people are incentivized to avoid. Even at teams that claim to be blameless. If they’re still not doing root cause analyses when things break in production, they’re not suddenly going to engage with a document that asks them to think about failure in advance. It’s always easier to avoid an issue through ignorance.

So when QA shares a document full of risks and open questions, the path of least resistance is to not engage with it. If you didn’t read it, you didn’t see the risk. If you didn’t see the risk, it’s not your problem. When something blows up in production, the question becomes why QA missed it — not why the team never weighed in on the plan that flagged it three weeks earlier.

This is what happens when quality is treated as QA’s job instead of the team’s. Developers ship to QA and move on. Product managers track feature completion, not product quality. QA ends up making risk calls on behalf of people who were never in the room, and then owns the outcome when those calls turn out to be wrong.

The Format Makes It Easy to Hide

A document makes this dynamic worse. When you share a test plan async, people can skim it, leave a thumbs up, and move on. They’ve “reviewed” it without actually thinking about any of it.

I tried a different approach for a while. Instead of sharing the full document, I’d drop a summary of our QA planning session into the scrum team Slack channel — a short write-up of the risks we’d identified and what we planned to cover. Easier to read, less formal, more conversational. In all the sprints I did that, one product manager ever responded. He asked whether accessibility would be covered since we hadn’t mentioned it. That was it. One comment, one person, across the whole time I tried it.

I had pulled product and engineering out of the conversation entirely by making test planning a QA activity. Maybe it should have happened during sprint planning when everyone is already in the room. But I’ll be honest — I’m not sure they would have shown up to a separate meeting anyway. I had a product manager tell me once: “I trust the QA team, you guys are smart enough to figure this out.” Sounds like a compliment. It wasn’t. It was accountability dressed up as confidence.

What Happened When I Stopped Sending Plans Altogether

At some point I stopped. I would still conduct test planning with my QA team only. But we no longer shared a document, no Slack summary, nothing. The sprints kept running. The QA team kept finding bugs. Production failures kept getting prevented. On the surface, nothing changed.

I’ve been sitting with what that means. My first instinct was that it proved test planning doesn’t matter, at least not the formal upfront kind. But I don’t think that’s quite right. What it actually showed me is that the planning never really stopped — it just moved. I still ask product whether a feature is actually releasing before I bother testing it. I still ask which bug fixes are going out. I still make regression decisions after talking to developers during desk checks or through Jira comments. The thinking was still happening, just distributed across the sprint in small conversations instead of captured in one document at the start.

That works when QA is experienced enough to make those calls on the fly and trusted enough that nobody questions them. It probably doesn’t scale to a bigger team, or a less experienced one, or an org that actually wants to share quality ownership beyond QA. If the goal is just to keep the trains running, informal and distributed might be fine. But if the goal is to get product and engineering genuinely invested in quality conversations, a document nobody reads isn’t going to get you there. Neither is quietly doing the planning yourself and not telling anyone.

Meet Them Where They Are

For teams that are afraid of accountability, don’t open with a formal meeting or a document to review. Start with a question. Drop something in the team Slack channel: is performance a risk this sprint? Are there features that might not ship and don’t need full coverage? You’re doing test planning. It just doesn’t look like test planning yet.

The goal is to get people used to talking about risk at all. As the team gets more comfortable with those conversations, you can add structure. But if you lead with a calendar invite and a document, the people who were already avoiding the conversation will find a reason not to show up.

When the team is ready for it, a short conversation at the start or end of the sprint — fifteen minutes, same questions the document would have answered — does something a document can’t. It puts people in the room. Engineers flag things that change the regression scope. Product clarifies what’s actually shipping. And when something comes up in production later, nobody gets to say they didn’t see it. They were there.

If you want a reference for what to cover in that conversation, the sprint test plan post covers exactly that. Use it as your agenda.

Write It Down After

Once you’ve had the conversation, capture it somewhere. Meeting notes, a Confluence page, a comment in the sprint ticket. If you’re using an AI companion on your Zoom calls, it probably already did it for you.

The document is still worth having. It’s a reference point when things get chaotic mid-sprint, and it’s a record that the conversation happened at all. But it should be a record of thinking the team already did together, not a request for engagement from people who were never going to give it.

The long game here isn’t a better test plan template. That’s what QA maturity actually looks like to me — not QA owning quality more thoroughly, but QA needing to own it less.