Every few years someone announces that quality assurance as a job is finished. Developers will test their own code. Automation will cover the rest. Users will report whatever slips through. I have heard this argument for most of my career, and the companies that acted on it tend to show up later asking why their release quality collapsed. Let me lay out why the industry still needs a dedicated quality function, in plain terms.
Someone has to represent the user in the room
A developer is paid to build a feature and is, quite naturally, focused on making it work. A product owner is focused on scope and dates. Almost everyone in the planning meeting has a reason to believe the thing is fine. The quality role exists to ask the uncomfortable questions. What happens when the file is empty? What does a brand new user see on the first screen? What breaks if two people do this at the same moment? Without a person whose job is to think that way, those questions do not get asked until a customer asks them for you.
Testing only your own work has a blind spot
I have deep respect for developers who write strong unit tests, and every healthy team needs them. But a person who just built something tends to test it the way they built it. They walk the path they had in mind. They rarely attack their own assumptions, because if they had seen the flaw in an assumption they would have coded it differently. Independent testing exists precisely to come at the work from outside the author's mental model. That distance is where a lot of real defects are found.
Quality is more than the absence of bugs
A dedicated function looks after the things that fall between the cracks of feature work. Whether the product meets accessibility standards. Whether it is secure against common attacks. Whether it holds up under load. Whether behaviour stays consistent across the browsers and devices real customers use. Whether the release process itself is reliable. These are not any single developer's responsibility, and when nobody owns them they quietly rot until they become a crisis or a headline.
The economics are not subtle
The cost of a defect grows the later you find it. A problem caught while the requirement is being written costs a conversation. Caught in development, a code change. Caught in a release test, a delayed release. Caught by a customer, it costs support time, engineering time, a fix under pressure, and trust that is slow to rebuild. In regulated areas such as payroll, finance, and government services, a defect in production can also mean penalties and legal exposure. A quality function is not a cost centre. It is insurance with a very good payout ratio.
Speed and quality are not opposites
The modern objection is that QA slows teams down. Done badly, a slow manual gate at the end certainly does. Done well, quality work is what lets a team move fast without fear. A solid automated regression suite means a developer can change code on a Friday and know within minutes whether they broke something three modules away. Early involvement means fewer surprises late. The fastest teams I have worked with were not the ones without QA. They were the ones where quality was built in from the first conversation.
What good looks like now
The role has changed, and that is healthy. The modern quality professional writes automation, works next to developers rather than in a separate phase, coaches the team on testing habits, owns the exploratory and risk based testing that scripts cannot do, and keeps the nonfunctional qualities visible. Less clicking through checklists. More engineering, more influence, more prevention.
The bottom line
The industry needs QA because software is built by people under deadline pressure, for other people who cannot afford for it to go wrong. You need someone whose job is to see it from the second group's side. Remove that role and the work does not disappear. It just gets done by your customers, in production, at the worst possible time.