Maybe getting rid of your QA team was bad
Many software companies have reduced or eliminated dedicated QA teams, betting on automated tests and developer-owned quality to save costs and speed releases. Engineers and testers in this thread argue that while unit and integration tests are essential, they rarely replace skilled human QA, whose product knowledge, exploratory testing, and defect triage catch edge cases and UX issues before users do. The conversation repeatedly returns to incentives: QA is treated as a cost center and second‑class career path, leading organizations to underinvest in it until mounting bugs, regressions, and customer pain expose the hidden cost of “move fast and break things.”
Role and Value of QA
- QA is described as both a distinct skillset and mindset, not just “people who click buttons.”
- Strong QA teams surface edge cases, UX issues, and “papercuts” that automated tests and devs routinely miss.
- Good QA often knows the product’s real behavior and user workflows better than devs, PMs, or sales.
- QA is framed as risk management and brand/reputation protection, not just bug-finding.
QA vs Automated Testing & Dev-Testing
- Many argue devs should and must own unit and integration tests; QA’s testing is complementary, not a substitute.
- Automated tests are powerful for regression and “happy paths” but are seen as weak on unexpected user behavior, complex flows, and visual/UX correctness.
- Code coverage (even 100%) is called out as a poor proxy for actual product correctness.
- Some posters report teams with no QA but heavy investment in automation and strong ownership, claiming higher velocity and acceptable quality.
Organizational Models and Anti-Patterns
- Classic “throw it over the wall” QA is widely criticized: QA gets code late, under time pressure, becomes a bottleneck, and is blamed.
- Successful patterns described:
- QA embedded with feature teams, involved in requirements, risk analysis, and acceptance criteria from day one.
- QA as gatekeeper with real stop-ship authority in higher-risk domains.
- SDET/QE roles writing frameworks, end-to-end tests, and tooling.
- Outsourced/low-skill or poorly integrated QA often degenerates into noise, duplicate bugs, and mistrust.
Status, Incentives, and Cost-Center Dynamics
- QA is often treated as a low-status cost center, first in line for cuts, with weaker hiring and promotion paths than engineering.
- Talented QA frequently leave for better-paid dev or product roles, creating a self-reinforcing decline in QA quality.
- Metrics like “bugs found” or story points can distort behavior; firefighting and visible heroics are often rewarded more than quietly preventing problems.
- Some engineers say caring about quality is a career liability in “move fast” cultures.
Domain, Risk Tolerance, and “Users as QA”
- Thread distinguishes SaaS/consumer apps (where fast rollback is possible and bugs are tolerated) from safety-critical, regulatory, on-prem, or mobile contexts where rollout/rollback is slow or failure is unacceptable.
- In many mass-market products, users are effectively used as testers; this is strongly criticized but acknowledged as economically attractive.
Practices People Like
- Exploratory testing, bug bashes/sniff tests involving the whole org, and QA-led risk analysis and fault modeling.
- QA as customer advocate and second-line support, maintaining test environments, data, and realistic scenarios.
- Viewing QA as “testing and exploration” or “risk analysis” rather than a post-hoc quality filter.