I saw @nat say the above and feel like this needs to be discussed more.
What does your quality and testing work look without test management tools?
How do you find confidence in coverage?
What do you do to ‘make up for it’?
2 Likes
i’ve worked with test management tools like TestLink, Rally & JIRA in my 16 plus years of career and honestly, they become very important once team scale. It’s not just about storing test cases -its about visibility , traceability and team coordination.
Without a test management tool, collaboration gets harder, especially in larger teams. Smaller teams can sometimes manage with shared Excel sheets or light weight tracking, but that usually doesn’t scale well.
If there is no centralized repository to track the matrix than definitely confidence level drop .Tool itself is not a solution disciplined process and coming up with new solutions based on new problems and communicating it with team matters.
Often I have it a bit like the below Meme. The tools shape us and then we shape the tools.
Depending on the structures the team and organization needs.. it depends. as usual.
1 Like
I tend to solo test usually across multiple projects, occasionally utilise a phone a friend model for say a security risk deep dive where a testing friend is more skilled than I.
Also no test management tool in over 15 years. *No spreadsheet either.
Confidence much higher, higher quality, deeper testing, more collaboration with developers identifying most important things right now often on daily basis.
Reduced waste, decrease control over testers and increased empowerment and trust of testers, reduced the idea as a separate thing from development which reduces handover points, reduced rework when things change constantly.
Very little to make up for.
I understand how it could be different where say a team of ten testers were needed on an app, but even in those cases some of those down sides of a test management tool should still be considered and find a balance.
I should also clarify I view test cases as being for developers and automation engineers and not really for testers at all, they can carry the same issues on a highly empowered tester environment, this might be a key impact on the perceived need for a test management tool.
2 Likes
I actually love that this became a separate discussion 
I genuinely think this question depends heavily on scale and complexity. In my case, I’m leading a team of 8 QAs, each owning their own product line. We have daily releases, multiple parallel feature streams, feature flagging and ongoing automation expansion.
For us, a tool like Testomat isn’t just about storing test cases. It helps us:
-
close gaps in understanding new features across product lines
-
make coverage visible when changes happen fast
-
manage the transition from manual tests to automated ones
-
track what’s stable, what’s flaky, what’s missing
Our E2E tests are synced with it, and we manage automation progress there as well.
Spreadsheets can absolutely work, especially when you’re 1–2 QAs on a project. But once the team grows and you need:
-
historical traceability
-
visibility across multiple products
-
structured regression management
-
reporting for stakeholders
spreadsheets start breaking silently.
Another honest factor is cost 
I’ve often seen resistance to tools simply because spreadsheets are “free”. But as a lead, I’ve always seen it as part of my role to justify the investment, not in the tool itself, but in process stability, transparency, and risk reduction.
Tools don’t create quality but teams do. But at a certain scale, not having structured visibility becomes a risk in itself, IMO.
1 Like
“Shifting-left” implies no test management tool. Automated checks are living documents that replace the test management tool.
1 Like
This could be a forum post on it’s own. 
Could, or do unit tests cover the necessary testing? Or how do you see the difference between unit and automated checks?
1 Like
Hehe, thanks Rosie for spinning an interesting conversation on it.
I think it’s highly depends on environment, culture and teams relationships. I didn’t use any test management nor excel for the last 10 years due to super fast start up culture when changes were going to production every minute. Maintain test documentation in test management tool or in excel was not sustainable. I also didn’t have PM nor any stakeholders checking our work or signing off release. Team decided if feature is ready to be pushed to prod.
As organisation we culturally focused on:
- high trust, high performing team
- you build it, you run it, you own it
- no blame culture, no finger pointing, working together through unknowns and challenges
- open to failures culture that learns from it and support each other
On technical side we focused on:
- a lot of unit tests; PRs, service, any integration can’t be pushed without tests
- API tests
- a lot of FE component tests
- E2E test automation involved automating only core user journey; our FE automated tests didn’t grow much and it was intentional approach; it was meant to be thin layer in automation
- strong monitoring and observability systems in place; I have introduced it as part of user story and part of release readiness; e.g. a new service/important feature can’t go live with no monitoring in place.
We were many teams with up to 10 QAs. We could work differently in our teams, we never agreed we should use same tool in each team and centralised it. We held high standards for delivery, double down on collaboration and automation.
All testing documentation was captured in the same place where team wrote requirements and technical implementation; it was holistic feature delivery from ideation to post release monitoring. Everyone in the team worked with same docs, systems and there was no divide between QA and Devs.
It might sound loose and maybe chaotic, but it worked for us at that time. At some point we went too fast and had to slow down to capture holistic view where we were, but somehow we never thought of any test management tool. I am not sure I would want one now. I think it divides devs and QA. I can be wrong.
3 Likes
Today I discovered that at least one person on team did not know what CI/CD stands for.
I agree with Jesper, the tools start to shape your language a bit. Small team, very small need for bigger words and bigger tools. I used a TCMS 2 years ago in my old job. It was always hard work, but I did it. In the new job, no such scale, and no need to keep “pushing” as defect areas are more fluid and rely on customer reports more, just by virtue of the environment.
1 Like
I’ve always used Test Management Tools and the reason has always been due to be able to communicate the detail of testing across the business and customers. If you don’t need to do that, great. But I like the fact that anyone in the organisation can look at any testing in progress or historic in a readable form, balancing the complexity of the testing that engineers understand with complete transparency.
Don’t forget either that most test management tools come with an open API. So in our automated testing, we can point key milestone regression testing to post the results to the TM tool. So you can make TM Tools slow, but thats a process choice - I don’t think its a feature of the TM tools that they’re systemically slow.
Now I’m not a campaigner for Test Management tools. I think what @nat mentioned above is very powerful. I get it. So maybe one of the open questions is, how transparent to the wider business and customers does your testing need to be? If you need to be transparent without a TM Tool, how do you do it?
2 Likes