But I’ve had conversations expressing frustration about whether it’s a thing that should even exist.
That in an agile, continuous delivery, and continuous quality type world that we live in that the concept of having to have test case management tools to micro-manage all the tests feels like such an out-of-date practice.
How’s test case management currently looking in your life?
Is test case management dead?
No, it works great
No, but it’s heading there
Yes, but it’s coming back
Yes, it’s non-existent
0voters
If we were to design how to do testing in today’s world, would we really think it’s a good idea to document tests to the extent that we do?
What other profession takes on such a tedious and pedantic approach to managing their work?
Who is doing testing with no test case management tools? And what does that look like for you?
Now call me a dinosaur (ok…don’t) but I can’t imagine being without it right now. What you put into test management like any other task, has to be efficient and valuable of course. It should not be a chore that blocks productivity. But the vital aspect for me is what you get out of it. So for me:
Devs and product managers see what you’re going to test
tech testers can see where they are in automation of the regression pack, what they can automate next and what they’re never going to automate
I can get reports that monitor executions, see blockages in the processes, understand trends and drive further efficiency improvements and target maintenance
Geta graphical picture of test coverage
Organise regression packs so you can pick and choose what’s needed
Support the relationship between manual and automated testers.
I am a firm believer in the old proverb, if you can’t measure it, you can’t manage it. If you want to persuade the people above you for further investment, you can give them facts from the Test Management tool to help your case.
However all that said, I love the idea of shaking this particular tree. There is nothing new coming from test management tools that is exciting - even adding Gen AI in my opinion. So its a good time to open this up, I’ll be watching this one
Personally I only see it in huge legacy applications, where there are test cases & test management tools. We are currently looking for one because there is no balance over all the teams and no structure or who does what.
So I’m not saying it’s useless, not at all. It’s just thinned out for small teams. Most of the times single tester teams.
I’ve had mature teams where you didn’t need test cases and a set of regression. We just went through the app on “gut feeling” and marked Section X and Y as “done”
It was a very mature company with unit & mutation tests + API/integration tests.
Generally at would integrate test cases to where you have the work been tested. Jira, Azure DevOps et.al. Not in a separate tool or function.
In heavy regulated spaces, it is required to have traceability to formal requirements. This could also be the case for the EU security regulations, which I’m currently working on.
Context must be considered as well. Especially with regards in what kind of industry you work (@jesper beat me to it hehe).
For example from my own experience, in a medical device company it is required to have a well documented and maintained test case set, which forms part of the full traceability (which needs to be shown for example to the FDA).
The better you have organised your test case management (structure, coverage, tool integration), the easier it is to ensure your full traceability
I don’t think test case management is dead yet — but the way we do it today doesn’t really fit how teams work now.
In a world of agile and continuous delivery, having to manage every single test step in some separate tool feels outdated. Quality should be part of the team’s everyday work, not something handled somewhere else.
If we were starting from scratch, would we really design it like this — with long, boring documentation that only one or two people ever read?
Instead, I think test case management needs to live where the team is already working — like in Slack or Teams — not off in some tool only testers have access to. Quality is everyone’s job, so it needs to be visible and accessible to everyone, not locked behind licenses or separate logins.
Also, not all testing is the same. Sometimes, you just need to write a quick test idea or charter. Other times, like with compliance testing, you do need detailed steps. That flexibility is missing in a lot of tools today.
In fast-moving teams, it’s too slow to write everything down. But we should still capture the high-level strategy — what we’re testing and why — together as a team. And again, that should happen right where we already work.
It’s definitely not dead yet…in my org, I’ve seen testers let go or rated poorly during appraisals just because test cases weren’t documented. And these were brilliant testers. It honestly breaks my heart. I feel like writing test cases has become a way to “show proof of work.” Unlike devs who can point to lines of code, testers are expected to show documentation. But if you ask testers about the value of test cases, you’ll hear a different story most don’t enjoy writing or maintaining lengthy ones.
We must absolutely “show proof of work”, @komalgc. Testing traceability is fundamental. But, more important to this is our need to have some documentation in place to help our own future selves should the need arise for us to retrieve and speak to any archived test results. Wouldn’t you agree?
Really not a fan of test cases or a system to manage them.
Seen so much waste associated with them and testing itself swaying very much towards a model that really suits machine strengths as a result.
There can be exceptions though, large, complex, regulated environments or you have detailed calculations for example I would in portfolio performance calculations, doing a six year prediction or look back involves so many variables where every variable to 6 decimal places was important was hard to do without a script. Automate that script though.
The job adverts out there suggest test cases and test case management is still common.
Motivation and personal job satisfaction is a major element for me and I know there is a risk of bias as a result. Its just not fun or fulfilling in any way and the perceived waste and low value compared to other models can demotivate the tester even further.
I find more advocates are in management positions rather than those on the ground doing the testing, is it an easier way to manage and control the team and does that outweigh the potential waste or is it a valuable necessity where the this is so dull element needs to be cast aside.
I wouldnt say test case management is dead, but it’s definitely not what it used to be.
Instead of traditional test cases, i have seen people use lightweight approaches like checklists, shared docs or just relying on automated tests. It is not dead but its definitely changed space and depends on a lot on team, product and how mature your processes are.
You might find it interesting that the full quote by Deming was “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.”.
Also, it’s cousin - “What gets measured gets managed — even when it’s pointless to measure and manage it, and even if it harms the purpose of the organisation to do so” is worth pondering from time to time.
I would say we can decide the process based on the nature of the projects. If it’s a standard and stable project write down the test cases, go with the books. You wont regret. Even where we have test cases written and documented, it’s not necessary to follow only that. I suggest the team to play around after the code drop and do few rounds of exploratory testing.
For quicker and new projects, we can go and do a exploratory testing.
We don’t need to follow the typical mundane template for test cases, I would suggest to tweak based on your needs.
I’m not surprised I misquoting an original quote that was made, I’m actually quoting what a manager said to me many years ago but I fundamentally believe in the principle I’m talking about.
Of course, if you have measures part of managing them is challenging them and evolving them. My goal with the measures is to ask “Are we improving?” and “Are their areas that are staying stagnant or getting worse?” and create an objective feedback loop. Some but not all come from our Test Management system.
Measures are not about managing people and I definitely wouldn’t support that, but depending on the organisation your in, measures are a method of communication inside and outside teams that are part of managing effectively. Thats my opinion of course and I’d be thrilled to know how people manage without them.
In my case as you know testing in cars, testcases are created by us testers itself. So, you can find testcases with different styles. I have also seeing a lot the situation that you start in a project or you are new in your company and stat to execute someone else testcases (maybe a colleage that still works there or someone that does not anymore). Man, a lot of times testcases are quite a mess or they do not test the thing in question or the test is somehow vage. So we need to correct those testcases, maybe create more testcases from one or expand it to test better. But this is just something we do based in our own cryteria, so no process no managament. I feel again that in automotive sometimes this control techniques are missed.
None of the above. Of course it is not dead but it isn’t the only way of managing and tracking in software development. Test cases and managing them get a bad rap from some quarters but there are still places that successfully use them, and others that don’t.
As always with these things context will answer the questions so while it might be in some companies who use alternative methods, it will be thriving in another.
Agile + shift-left + automation + … world = Test cases management is dead. Test code is the living documentation.
But, there are test cases which can not / should not be automated: One small village of indomitable testers with test cases still holds out against the invaders
Thinking about this and reading through the replies, it feels like this is a combination of trust and regulatory need.
Understanding a need for evidencing and what granularity is needed to satisfy regulatory organisations will always influence how you record “test cases” but you can choose how those are documented especially if there are automated checks that are well integrated with reporting. And that reporting is inclusive of any testing you do over and above that.
Trust is the bigger factor in most cases though and will usually inform the question of why are we doing all this test case management?
Do you trust the development team to deliver high quality code?
Do you trust the unit and integration tests?
Do you trust the test team to do the right testing?
Do your stakeholders trust that the test team are doing the right testing?
etc.
So if you find yourself spending an unfeasible amount of time managing test cases ask yourself:
Who are you doing this for?
Is there a lack of trust that is behind this?
Can you improve the trust and reduce the test case management?
Increasing trust within a wider team and in the quality approach could help build better team dynamics too, which helps everything.
