Having joined a company that didn’t use a proper test management tool, it was a bit of a shambles to understand the testing efforts that had gone on before I joined.
So at the very least, I think they’re good tools for newcomers to a team to understand what’s going on testing-wise.
Great question — but I think it’s missing some context. Looking at test case management in isolation, as if it’s just about documenting and organizing test cases, misses the broader purpose it serves in modern software testing.
Test case management isn’t (and shouldn’t be) a siloed activity. It’s one part of a larger ecosystem that includes test execution, defect tracking, coverage analysis, requirements traceability, tester workload distribution, and reporting. Most test management tools aren’t just about “writing test cases” — they’re about enabling coordination, visibility, and quality assurance across the entire testing effort.
In complex environments, especially those with regulatory needs, distributed teams, or multi-release dependencies, removing test case management would introduce more chaos than agility. That said, how we manage tests does need to evolve — lighter, more integrated, and automated approaches are being favored over rigid, waterfall-style documentation.
So no, test case management isn’t dead. But it is maturing — and hopefully, becoming a more seamless part of broader test and quality management strategies rather than a burdensome checkbox exercise.
Curious — for those saying they’re doing testing without test case management tools, how are you managing traceability, planning, and progress visibility?
I love this angle.
I wonder if ‘test management’ would be better than ‘test case management’ as a way forward, it feel more broad, and inclusive to other practices.
What do you think? 
What I would like to add that test case management is also quietly becoming a collaboration layer not just for testers, but for the whole product team. It is where QA, developers, BAs & even stakeholders can align on what is being tested, why it matters, & whether we are ready to ship. When done right.
Maybe the real question is not whether test case management is dead… but whether our tools are doing a good enough job of staying alive in a world of agile, AI & continuous delivery.
I just started a new job, and yes, there are no test cases, well that’s not true, there are no system or subsystem tests. Lots of component tests… and for different reasons that component tests also never get logged in a TCMS, the system tests probably also never got logged. So I’m starting fresh, and a TCMS is way down on my list.
I agree, @andres_gr customers, testers and the regressions we find together are the only test cases worth tracking… if we can find the time. As thing mature, and as one moves further along to mission-critical products and the delivery /production and SaaS. Anything where you deliver to the final customer, starts to warrant more measurement. Moreover I also find vague test case implementations that got written to tick a TCMS box, cost us more than it’s worth if they miss-lead or stop us exploring more freely.
I do think we could do better for the art of software Quality, if people using Excel did not get so much of a stigma or belittling feeling applied to them. We can all benefit from some rigour even in an agile world.
Having a test management tool is an absolute heroine is keeping all of the test evidence in one place!
Imagine not having a central place to store all the test notes. It can lead to chaos! Worst case scenario is you use excel 
(ive walked into that several times!)
Normally these test management tools are so flexible these days. We have for example an exploratory testing template that we use.
Also imagine complex systems where it’s useful to store test steps. For example we test ‘networks’ which is not your usual UI type testing, so it’s beneficial to write it down and share with other team members.
I do.
IMO you assume its always need to the same degree, but different contexts need it to different degrees (including if at all).
In my context I use a Confluence page per user story which is living document. I note there what I plan to test as well and what I found out. Every then and now I discuss my plans and my findings with relevant people.
I consider myself being in a high-trust team. For visibility of work we mainly work with our Scrum board. While I have some tasks there, they are more superficial representing chapters of the use confluence page. Who ever wants to take a deep dive can look at the Confluence page.
People can look it up easily but I think the do it really on their own. I show it my pages anyway frequently. No need for control.
What do you mean by traceability? Of requirements to test cases?
As I have more a note style of documents, I don’t have typical test cases.
How to I ensure that I cover the right things? I talks to my team, ask them for risks and priorities and craft my test plan/report with them together.
One could say that I do a more loose approach to session-base test management. Some call it thread-based test management.
You may also want to read here.
How well did I explained my situation?
In my view, it depends on what kind of testing we’re talking about.
If your tests are automated, you already have the documentation, it’s in the test code, enriched by static analysis, version control, and naming conventions. In that context, traditional test case management tools often become redundant. They’re extra overhead with little added value.
If we’re talking about human-driven, ad hoc tests, then the real question becomes: what exactly are we documenting?
Rather than trying to force everything into a tool designed for step-by-step test cases, maybe we should be asking:
In many teams, test case management tools are sticking around by inertia. But if we’re serious about modernising how we think about testing, it’s worth challenging whether they still serve a meaningful purpose.
Totally agree! It sometimes is just required. I’m currently overseeing 7 teams and we have no test management tool, we are going to look for one. Now everybody “does what they want” and there is no “proof” of the app being tested and testers get blamed all the time ;(
While it’s mostly config issues in prod, but they often mention “it’s not tested” so I would love some proof <3
So our search for “the test mangement tool” for the company has begun! 
good luck in finding one! I had to do a similar activity.
I’ve felt in the past that it often became a managers people management tool rather than a test management tool.
Often used to address trust issues and put more emphasis on evidence of testing rather than good testing which in turn added gamification to the testing and changed its focus.
I do though recognise that it can often be a trust problem particularly when something goes wrong and someone want’s proof of testing, they are then not interested in that proof at all until the next time something goes wrong.
Now I have what I view as better ways to address that trust, coaching and training of both testers and others to understand what the testing involves alongside levels of reporting, sometimes it just test session being reviewed, shared and available yet I still see that trust issue coming back for some teams.
I dont have the answer for this yet, however I remain wary of the test management tool separate from development that it may be being used so solve a people rather than test problem that has its own downsides.
I think if that is considered and understood and other actions are in place to address the trust issues it can still be of value, but adopt with caution.
I totally agree, I’m currently in a big hierarchy company 
But currently our teams either have: no test scenario’s/cases or very very poorly documented and if they are absent, nobody knows what to test (since other people have to step in but have either: no product knowledge or don’t know how to test).
Then again, currently there is no single overview of what which team or tester is doing. It’s not our intention to control people but more like, what if someone gets sick. Because they only know their own application and cannot help on other projects.
For each release to prod, we have to submit proof of testing, which now is … well either an email saying “sure/GO” or “Our tester did everything” without any legit proof of testing. Or without any knowledge of the tester… since this is asked to the scrum master and sometimes not even consulted with the tester (… but that’s a different problem )
One of the main problems is architecture, they made changes I don’t even dare to explain since they are so bad for quality & testing (literally pushed back testing by 3-6 WEEKS PER RELEASE) . So yea for me there are a whole lot of reasons that our team wants this.
One of the reasons I wanted to do this: The unbelievable Powerpoint?
I think test case is like a documentation which helps the new and existing team members to know the system.
So to manage them a system is needed. It can help you
Its important to not just add cases but optimisation and keeping the set to an optimised number helps otherwise the number will start scaring you.
For me, and this may be a personality thing vs a skillset but writing test cases does several things for me:
I do wonder if the desire to ditch test case management is because the platforms where they reside are just terrible. I have only used a couple. One was a beast/expensive/and buggy (a tester’s nightmare). The other I found on my own when picking tools and I use it all the time. I love working with it and I’ve picked it up with three organizations I’ve been with. So, for me, test case mangaement is really helpful and a practice I’ll continue to use.
We’ve always referred to it as ‘Test management’, so we’re definitely for it, sure.
Test case management is definitely not dead, it has simply evolved.
At QAonCloud, we see test case management as a critical part of delivering quality at speed. While traditional bulky test case documents may be fading, structured and traceable test cases are still essential especially in agile and DevOps environments.
We use modern tools to keep test cases modular, reusable, and closely aligned with user stories. This helps us maintain clarity, ensure coverage, and support faster regression testing. Test case management also plays a big role in collaboration between QA, developers, and product teams.
So no, it’s not dead, it’s just smarter, lighter, and more integrated than ever.
Many clients ask for test cases, and in such scenarios, test cases are important. And if test cases exist then test case management is also important.
Test cases may look boring, but nowadays, with the help of LLM tools, we can generate test cases in a few seconds, so now it is a bit less tedious task as compared to earlier.
Also, we will keep seeing varying thoughts in the market for various things like test case management is dead, BDD is dead, Selenium is dead, etc. but even if new projects don’t adopt this approach there are plenty of legacy projects that works on this principles and hence this will exist for at least for next couple of years and then after that depending on market condition we can conclude if they are dead or still alive.