Document less, share more: A modern take on test evidence

Document less, share more: A modern take on test evidence

Do we still need test case management tools?

In my experience, not really. At least, not in the way most teams are still using them.

Test case management tools are everywhere, but they’re not helping us make better decisions. In modern software teams, they’re often maintained out of habit or because someone, somewhere, still wants to see a report at the end of the sprint. But ask anyone actually doing the testing, and you’ll hear the same thing:

“I spend more time updating the tool than I do testing.”

That’s not how documentation should work.

If a tool adds more overhead than value, it’s a broken tool. And it’s time we had a proper conversation about why we’re still clinging to this particular one.

Automated tests are already documentation

When we’re talking about automated tests, we don’t need a separate documentation layer. The tests are the documentation.

• The test code tells you what’s expected
• The naming and structure provide intent
• The version history tells you when and why things changed
• Static analysis tools can surface gaps or trends automatically

   

In that context, test case management tools are redundant. They don’t improve the work, and they don’t improve visibility. They just add friction.

Human-driven tests are about insight, not steps

Now, when it comes to exploratory testing or investigative work, things get a bit more nuanced. But here too, test case tools often miss the point.

If the test is repeatable and high-value, you’ll automate it. And once it’s automated, we’re back to square one: documentation lives in the code.

If the test is not repeatable, like a one-off investigation, a risk hunt, or a spike into unknown behaviour, then writing a test case for it doesn’t make much sense. You’re not preserving steps; you’re preserving insight.

That insight might be worth capturing, but not as a step-by-step case. More often, it should be captured as:

• A note in a ticket
• A comment in a PR
• A risk to highlight on a dashboard
• A story to bring to the retro
  
  

What matters isn’t the format of the documentation, it’s the reason for it.

Ask better questions about what’s worth preserving

Rather than trying to force all testing into a single system, we should be asking:

• What information is actually worth preserving?
• Who is it for?
• What do they need to do with it?
  
  

If the answer is “we need to report on testing to leadership,” then maybe that’s the problem to solve, not by shoehorning everything into a test case tool, but by designing better ways to surface insight. A lightweight dashboard that shows trends, risks, and signals from both automation and human testing might go further than any status report ever will.

Test documentation isn’t dead, but it needs to grow up

I’m not talking about abandoning documentation entirely, but we need to modernise it. 

The work we do as testers, quality advocates, and software professionals deserves to be visible. But that visibility should serve a purpose. It should help the team, the business, and future us make better decisions.

This is something I talk about a lot in the QED framework—how to be intentional about what we collect, how we store it, and how we share it. If we want to lead with quality, that starts by treating information like a product: useful, purposeful, and maintained only when it’s worth it.

So here’s my question to you:

If your test case management tool disappeared tomorrow, what would you actually rebuild?
And who would you be building it for?