Should QA exist?
Whether dedicated QA teams should still exist is contested amid growing reliance on automated tests and AI-assisted tooling. Contributors argue that while developers must own much of the testing and automation, skilled QA specialists add unique value in exploratory testing, uncovering requirement gaps, understanding complex product behavior, and meeting regulatory or high‑reliability demands. Others counter that poorly implemented or under-resourced QA can become slow, low-value “button pushing,” suggesting that organizational structure, incentives, and QA skill level matter more than the simple presence or absence of a QA role.
Existence and Ownership of QA
- Broad agreement that “quality assurance” as a function must exist; disagreement is about who does it and how it’s organized.
- Some argue engineers should own quality end‑to‑end; dedicated QA encourages “throw it over the wall” behavior and slows release.
- Others say quality is a system involving engineering, product, design, and operations; dedicated QA are specialists in that system, not a crutch for bad engineering.
Value of Skilled QA vs Bad QA
- Many anecdotes of excellent QA finding subtle, high‑impact bugs, cross‑feature interactions, and timing issues that devs never considered.
- QA often become the deepest experts on the product and its real behavior, helping product, support, and design.
- Strong view that most QA in the wild are undertrained “button pushers,” repackaging dev tests and adding bureaucracy; this fuels skepticism about the role.
- Poor org design (e.g., remote offshore teams running dev‑written scripts) turns QA into expensive red tape that finds little.
Automation, Testing Strategies, and AI
- Debate over the “testing pyramid”: some claim it’s outdated; advocate a “testing hourglass” with many unit tests and many UI/API tests, fewer mid‑level integrations.
- Others emphasize test cost along a “would you run it” axis: fast deterministic tests at bottom, flaky/slow/expensive ones at top.
- Conflicting views on unit tests: some see them as cheap, high value; others see them as expensive, low value compared to smoke/E2E tests.
- AI is seen both as:
- A way to cheaply generate automated tests and supercharge good QA.
- A reason QA becomes more important, since coding is automated and human verification/oversight dominates.
Human Testing, Exploratory Work, and Product Knowledge
- Exploratory and adversarial testing (breaking flows, odd timing, network failures, multi‑device behavior) is widely cited as where good QA shine and automation struggles.
- Humans are needed to validate UX, “does this make sense,” and real‑world usage patterns, not just specification conformance.
Organizational Structure and Incentives
- Arguments for independence: QA analogous to audit/red team; shouldn’t be beholden to the same managers and incentives as builders.
- Counterpoint: siloed QA, long queues, and lack of collaboration are destructive; embedded test engineers or SDETs within teams work better.
- QA is often underpaid, first outsourced or cut, and used as a dumping ground for glue work, which degrades quality of practitioners and outcomes.
Domains and Risk Levels
- High‑risk and regulated domains (medical devices, aerospace, enterprise contracts, compliance frameworks) are described as requiring robust QA and formal test evidence.
- Consumer/social products often accept weaker QA in favor of speed and growth; “does it have users” can trump correctness.