If you started somewhere, and they had no established test case management system, how would you make the choice of it it’s the right thing to introduce one?
From my perspective, I’d prefer to keep exploratory testing notes, and have any test cases automated, with no manual scripts to maintain.
I feel like introducing a test case management system risks over investing in writing tests instead of doing testing. But am I missing something that makes the investment in writing manual test cases worth it?
I’ve heard the reasonable argument, that it creates a source of truth for expected behaviour. However, I can think of better ways to model that, other than using test cases.
I’d love to hear about when test case management systems and suites of scripts have been helpful for you in a meaningful way.
Context, there is only me and one other quality engineer, both only a few days into the job, and we won’t be doing all the testing.
I find some sort of manual test case management helpful for regression, when you have much repetitive stuff which you cannot automate for a reason (we have that). But I would not want to spent to much effort on it.
Our ex test manager pushed through that we buy the XRay plugin for Jira and know we pay around 10.000€ each year of license costs. Because of the Jira pricing model, that you always pay for the size of your Jira instance, not how many people are really using the plugin. Our instances is for 500 people, but not even 10 use XRay.
Imo its not worth that.
For a while we had templates of test cases in Confluence and for the execution we created Jira tickets and pasted there the templates. And we did an individual report in Confluence by linking the tickets there.
Even if I was just one person I would have a shared repository of test things (cases, charters, notes). A place that outlives me if I leave and help me remember stuff over time. Even more when there are two people. github, wiki, excel, .. doesn’t matter as such.
There is some sense in having this close to the dev’s stuff. So if they are in jira - or devops or SAP Solman over what ever, go there. align with them. Perhaps over time the test artifacts will require it’s own place - deal with that when you get to it.
When you start using any prefabricated system (eg test casemanagement tool) it will shape the way you do your work. Be aware of this in the tool selection. Check @TheyWrestleTest s work on this topic btw.
When you use Excel IMO it should be at least stored in a cloud for easier sharing and be able to handle collaborative editing.
Don’t use it with a classic network drive or just locally.
I too am concerned over an over reliance on scripted test cases. But, “from all the automators I’ve worked with” (because I’m sure there are some I haven’t that will disagree ), being able to pick up a test case thats been analysed, designed, executed until its passed - is their golden ticket it automating tests quickly. So to me the happy medium is writing that happy path test case for the purpose of automation but exploratory testing from beyond that.
The Test Management Tool really depends on how much you need to evidence your testing. If you don’t brilliant - do whats most efficient. If you do then you need to find that happy medium where you can evidence it, but do what you can to keep your testing approach efficient..and fun.
I’ve been in places where TCMS felt like overhead, slowing us down more than helping. Especially in early-stage teams or as QA team where more than one tester, the temptation is strong to stay nimble, keep things lean, and just document as we go. Exploratory notes + automation sounds efficient, and for some setups, it absolutely is.
But here’s where I’ve seen TCMS actually earn its place:
Onboarding: When new folks join, having some kind of structure even lightweight makes it easier for them to pick up where we left off, see what areas have been tested, and avoid duplication or blind spots.
Regressions : Especially when non-QA folks (PMs, Devs) start asking: “How do we know this part still works?”, having a source of truth to refer to (even if not exhaustive) helps us justify test coverage beyond gut feel.
Coordination: If testing starts getting shared across product/dev/QA, test cases (or at least structured checklists) give us all a shared language. Otherwise, we risk scattered notes, lost tribal knowledge, and “Oh, I thought you tested that” moments.
The goal isn’t to write tests all day, it’s to find bugs, prevent risks, and enable fast feedback. If a TCMS starts feeling like a documentation graveyard no one looks at, then yeah, it’s not doing its job.
If I were in your shoes, I’d:
Begin with something lightweight, maybe a shared Notion page, or running a checklist in Jira. Whatever feels natural to the team, not forced.
Focus on capturing what genuinely helps us test better not just ticking off boxes to say “we documented it.” If something isn’t helping us catch bugs or make smarter decisions, it’s probably not worth maintaining.
Would love to hear how you’re balancing things as the team grows!
From my experience, using a test case management system has been a double-edged sword.
The good part? It really helped us stay organized—especially on large projects. Mapping test cases to user stories, tracking execution, and pulling reports for stakeholders made life easier. I’ve also found it useful when collaborating across distributed teams—everyone stays on the same page.
The flip side? Some tools can feel bulky. I’ve worked on projects where maintaining the system became more work than testing itself. If it’s not tightly integrated with automation or CI/CD, it slows things down. And honestly, outdated test cases sitting in the system often go untouched unless someone actively manages them.
Overall, when used right, it adds value—but it needs discipline and the right fit for your workflow.
), being able to pick up a test case thats been analysed, designed, executed until its passed - is their golden ticket it automating tests quickly. So to me the happy medium is writing that happy path test case for the purpose of automation but exploratory testing from beyond that.
then you need to find that happy medium where you can evidence it, but do what you can to keep your testing approach efficient..and fun.