Lately, I've been spending some time looking into interesting companies. Part of it is curiosity, but mostly, I've been scoping out places I might want to work next 😅. One thing I'm noticing is that more and more companies don't have a dedicated QA or testing function. Now, that's not necessarily surprising - I know that plenty of teams distribute testing responsibilities across different roles. But responsibility is not the same as accountability, and it's got me thinking: do these teams really consider what happens to quality when no one is accountable for it it?
If your company doesn't have a QA team, do you think that means y'all aren't testing?
Of course not. Every team that builds software tests, whether they realize it or not. The real question is how well they do it.
Many think of testing as something that happens at the end of development - a final gate before release. But testing is happening at every stage of the product development lifecycle (PDLC). It's just not always intentional or particularly effective at catching what matters.
So, who's actually testing?*
*Even if they don't call it that
When there's no formal QA function, other roles may naturally take on parts of the testing process. And often this is done in ways that aren't structured or scalable:
- Product Managers might try to spot major gaps by clicking through new features before launch, relying on gut instinct, customer feedback, and a few hurried test scenarios to make sure things seem right.
- Designers run usability tests, but their focus is usually on the ideal user journey. Edge cases aren't always on their radar.
- Engineers test for code correctness but tend to focus on what they expected to happen rather than what could go wrong.
- Customer Support turns into an unofficial bug triage team, troubleshooting issues and reporting critical failures after they've already reached users.
So, yeah, testing is happening - kind of. But when no one owns it, gaps show up. Users become the real testers and, over time, quality declines, releases get riskier, and teams spend more time firefighting than building.
The risks of testing without testers
Every function involved in building software contributes to quality - but none of them specialize in it. And when no one's job is to be accountable for quality, testing can become scattered, inconsistent, and reactive.
Limited risk assessment: Without a QA function, teams might be testing, but are they testing what really matters? Probably not. Instead, it's a game of chance. Maybe they'll catch the big issues, maybe they won't. And good testers don't just find problems - they help teams anticipate what could break and prevent the worst from happening
Gaps in exploratory testing: Automated tests are great at catching regressions, but they don't think like a user (at least not yet. Maybe some AI tool will prove me wrong someday soon 🙃). Good testers are critical thinkers - they challenge assumptions, ask "what if", and catch the subtle issues that automation can't.
Inconsistent testing approaches: And with each team and function focused on their own goals, quality practices tend to be applied unevenly and when trade-offs need to be made, testing is often the first to go. Good testers adapt their approach to fit the business while making sure the quality bar stays where it should be.
Quality as a team effort
Now, the best teams I've worked with - whether they had a dedicated tester or not - understood that QA can't own quality alone. It's built into how the whole team works.
Product and design teams working with QA early: great products are built with quality in mind from the very beginning, with PMs, designers, and testers working together to test assumptions and usability before any code is even written.
Developers treating testability as a first-class citizen: writing clean, testable code is considered a best practice for a reason. When engineers write testable code, quality is just part of how great software gets built.
Leadership making quality a priority: quality a competitive advantage AND it also benefits the team. Cutting corners might save time upfront but dealing with the resulting bugs and rework slows teams down even more in the long run. Besides, shipping quickly doesn't mean much if you're shipping buggy products that get in the way of your users. When leadership prioritizes quality, teams can move fast without breaking things.
But "everyone owns quality" only works when there's someone whose job is to make sure it actually happens. Without that, ownership diffuses until it belongs to no one.
So as I keep looking at companies and finding more without dedicated testers, I'll keep wondering: do they even know what they're missing? I'll bet their users do.