Is Software QA Dead? What Quality Engineering Looks Like in the AI Era
Software quality assurance is the work of helping software behave as intended, from a single function to a busy application serving real customers. Testing checks whether a product works; quality assurance also shapes the practices, tools, and team habits that prevent defects from reaching people.
I’m Ermenildo V Castro, a Filipino software engineer in Seattle. Across large engineering teams, I’ve seen the same argument return every few years: either QA is finished, or no team has ever needed it more. Both claims flatten a real change into a slogan. The role has moved, and the work has spread across the people who design, build, and operate software.
That shift matters because software is changing faster, while users still expect it to be safe and dependable. AI coding tools can produce more code and more tests, but they cannot decide what failure would harm a customer, or whether a passing test proves anything useful. The hard part is not pressing the test button. It is choosing what to test, when to test it, and who should act when something fails.
What Is Software QA?
Software testing checks whether an application behaves as expected. A test might confirm that a payment total is correct, that a page opens on a phone, or that the service stays responsive during a surge in traffic. Quality assurance, often shortened to QA, is broader: it includes the methods and team practices that reduce the chance of defects in the first place.
People often use QA and testing as if they mean the same thing. That is understandable, but the difference matters when a company hires or assigns work. At one company, a QA engineer may spend most of the day running manual test cases. At another, the same title may mean building automated test tools, improving release checks, and helping teams find risky changes earlier. The title alone tells you little.
Testing also comes in several forms. Unit tests check a small piece of code, often a function, in isolation. Integration tests check whether components work together. End-to-end (E2E) tests exercise a full user task through the application, such as creating an account and placing an order. Regression tests rerun earlier checks after a change, looking for new failures in old behavior.
Other tests ask different questions. Performance and load tests examine speed and stability under expected or peak demand. Manual and exploratory testing let a person try unusual paths, notice confusing screens, and probe cases the test suite does not cover. None is a substitute for all the others. A small, well-chosen unit test can catch a basic calculation error quickly; an E2E test can reveal that a real user cannot finish checkout.
A useful starting point is the test pyramid, which describes a balance of test types rather than a pile of slow, brittle browser checks. Google’s advice to limit unnecessary end-to-end testing makes a similar point: put checks at the level where they are fast and reliable, then reserve full user-flow tests for behavior that needs them.
The key change is shift-left testing. Teams bring checks into design and coding instead of waiting for a separate test phase after development. Developers take more ownership of unit and integration tests; dedicated QA and quality engineers focus more on test infrastructure, automation, risk, and human exploration. The job did not evaporate. In many organizations, it moved up a level.
Why QA Still Matters
Good QA does not mean trying every possible input. That would take forever. It means finding the failures that matter, then building a sensible way to catch them before they reach a user.
- It protects people from avoidable harm. A failed login is annoying; a wrong medical dose or incorrect bank transfer can be far worse. In my experience, teams make better choices when they ask who could be hurt by a defect, not only how many tickets it might create. Reliable software is part of responsible work.
- It reduces the cost of late surprises. A bug found while a developer is working on a small change is usually easier to understand than one found after several releases have piled up. I’ve watched a simple missing check turn into days of investigation because the failure reached production and crossed team boundaries. Early feedback is cheaper than a late scramble.
- It makes releases less nerve-racking. Automated checks in a continuous integration pipeline can run whenever a change is proposed. If they are fast and trustworthy, a team gets useful feedback while the code is still fresh in everyone’s mind. DORA’s guidance on continuous integration describes practices such as frequent integration and fast feedback; a green pipeline should support judgment, not replace it.
- It helps teams learn what users actually need. Automated checks are good at repeating known expectations. People are better at spotting a flow that technically passes but feels confusing, unfair, or inaccessible. Exploratory testing is not random clicking; it is a focused effort to ask questions the existing test plan missed.
- It keeps speed from becoming a quality debt. AI coding assistants can make it easier to draft code, and that may increase the number of changes a team reviews. More changes mean more chances for gaps in test coverage, dependencies, and review to pile up. Frankly, a faster keyboard does not make a product safer by itself.
- It makes shared ownership practical. Developers can write tests for their code, while QA specialists help set standards, build tools, and spot risks across systems. When I’ve seen this work, neither group treats quality as somebody else’s chore. The result is clearer decisions and fewer handoff arguments.
The distinction between quality control and quality assurance is useful here. Testing a completed feature is quality control: it checks the result. Setting clear acceptance rules, reviewing risky designs, and building dependable test tools are assurance practices: they improve how the result is made. A mature team needs both. It does not need a contest over which job title matters more.
A Step-by-Step Guide to Modern QA
A practical QA process starts with a risk and a customer need, not with a tool purchase. The following steps work for a small product team as well as a larger engineering group.
- Name the behavior that must work. Write down what a user should be able to do and what must never happen. For a checkout flow, that could mean charging the correct amount, showing a clear error when payment fails, and not creating two orders after a repeated click. I’ve seen teams skip this step and then argue over whether a test failure is real. Clear examples save time.
- Rank the risks. Consider how often a feature is used, what happens if it breaks, and how hard the failure would be to notice. A typo on an internal page and a broken account recovery flow do not deserve the same test effort. This is where product, engineering, support, security, and QA should compare notes. The best priority list reflects user impact, not the loudest voice in the room.
- Choose the right test level. Put simple rules in unit tests, interactions between services in integration tests, and a few critical user tasks in E2E checks. Add performance tests where speed or capacity matters, and use human exploration for confusing or unusual flows. The goal is not to maximize browser tests. It is to get reliable evidence at a sensible cost.
- Build checks into the change process. Run quick tests locally and in the continuous integration pipeline for each proposed change. Keep feedback short enough that developers will read it and act on it. If a test is slow, unreliable, or unclear, the pipeline can become a wall of red lights that people learn to ignore. A test gate only helps when teams trust what it says.
- Review AI-generated tests like code. A tool may produce a test that mirrors the implementation, checks only that a function ran, or misses the real failure case. Ask what behavior the test proves, whether it would fail if the feature were broken, and whether its setup hides a problem. AI can provide a first draft. A person still needs to judge its value.
- Try the product as a person would. Explore the important paths with different devices, account states, and unexpected inputs. Check whether wording is understandable, keyboard use works, and error recovery is possible. An automated test can confirm that a button exists; it cannot always tell you that the button’s label makes no sense to a new user. Here’s the kicker: many serious gaps are about how a system feels, not just whether it runs.
- Learn from failures and improve the suite. When a defect escapes, ask why the existing checks missed it. Add a test at the level that would catch the problem reliably, update the risk list, and look for similar weak spots. Do not add a slow E2E test for every production bug by reflex. The OWASP Web Security Testing Guide is a useful reference for security checks, but a security guide cannot replace product-specific risk decisions.
Comparison Table: Dedicated QA and Developer-Led Testing
These approaches are not true rivals. A modern team needs developers who test their own changes and quality specialists who strengthen the wider system. Still, comparing the traditional manual-only model with developer-led testing helps explain why QA roles have changed.
| Area | Manual-only QA model | Developer-led testing with quality engineering |
|---|
| Main responsibility | A separate QA group runs test cases, often late in development | Developers test changes; quality engineers support shared standards and systems |
| Timing | Testing may begin near a release | Checks start during design and coding and continue through delivery |
| Common test work | Repeated manual checks and release sign-off | Unit, integration, and selected E2E automation, plus exploratory testing |
| Main strength | Human observation can catch confusing behavior and overlooked cases | Fast, repeatable feedback can catch many defects near the change |
| Main risk | Handoffs delay feedback; repeated checks can consume time | Weak tests can create false confidence; specialists may be spread too thin |
| Best fit | Small or changing areas where human exploration matters | Products with frequent changes and a need for reliable, repeatable checks |
Neither column wins by default. A developer-owned test can be shallow, and a manual test can be insightful. The useful question is whether the team has evidence that its important user tasks work, and whether it can tell quickly when that stops being true.
A dedicated QA group is especially helpful when a product has many services, strict safety or privacy needs, complex devices, or users with very different needs. But separating all testing from development can create a queue: developers finish a feature, QA finds problems, and the team spends time rebuilding context. Shared ownership shortens that loop.
In the teams I’ve worked with, the healthiest setup gave developers responsibility for tests close to their code while giving quality specialists room to improve test infrastructure, assess risk, and run exploratory sessions. No one role can see every failure. That is why the comparison should not be treated as a staffing contest. It is a question of how a team covers the work.
Common QA Mistakes to Avoid
Treating test coverage as proof of quality is a common trap. Coverage tells you which lines or branches ran during tests; it does not tell you whether the tests checked meaningful behavior. A test can execute every line and still fail to catch the wrong price, a missing permission check, or an unusable error message. I’ve seen teams celebrate a high coverage number while important user paths stayed untested. Ask what could break, and whether a test would notice.
Writing too many fragile E2E tests causes a different problem. Browser tests can be valuable, but they often depend on timing, network state, and changing page details. When small interface changes break dozens of tests, people start rerunning the suite or ignoring failures. Google’s guidance on keeping E2E tests focused is worth reading; a smaller set of dependable checks often gives better feedback than a huge, noisy suite.
Assuming AI-generated tests are correct is not a shortcut; it is a transfer of responsibility to a tool that cannot own the outcome. A test that repeats the same assumption as the code may pass while both are wrong. Review test names, inputs, assertions, and failure behavior. Try changing the code in a way that should break the test. If the test still passes, it may be checking the wrong thing.
Treating every AI output as if it were a fixed string can also produce bad tests. Code written by an AI assistant normally runs under the same rules as other code; if it has a defect, test it like any other change. But an application that uses a generative model may return different valid answers to the same prompt. For those features, check meaning, safety, and acceptable bounds rather than demanding one exact sentence every time.
Counting flaky failures as harmless noise slowly damages trust in the pipeline. A flaky test fails intermittently for reasons unrelated to a real product defect, such as timing or shared test data. Track the flaky test rate, fix the cause, and quarantine a test only with a named owner and a plan to restore it. Letting it sit in quarantine forever is just hiding the alarm.
Picking metrics without the people who use them invites bad incentives. Test coverage can encourage more test lines without better checks; bug counts can make teams reluctant to report problems. Useful measures include defect escape rate, mean time to detect, mean time to resolve, and flaky test rate, reviewed alongside customer impact and release health. Technical and non-technical partners should agree on what each measure means. Metrics are tools for learning, not a scorecard for blame.
Frequently Asked Questions
Will AI make software QA jobs disappear?
Probably not, but it will change parts of the work. AI tools can draft test cases, produce code for test scripts, and group related failures. They cannot reliably decide which defect would harm users most, whether a test captures the intended behavior, or when an unfamiliar result deserves investigation. Some repetitive tasks may shrink, while work in test architecture, automation, risk review, accessibility, and exploratory testing remains important. The job shifts from running every check by hand toward making the whole quality process more useful.
Should developers write their own tests?
Yes, developers should usually write and maintain unit and integration tests for the code they change. They understand the design and can get feedback while the change is fresh. That does not mean every developer must handle every test alone. Quality engineers can build shared tools, guide test design, and investigate risks that span several services or user groups. Shared ownership works best when the team agrees on what developers own and where specialist help is needed.
Is 100% test coverage necessary?
Usually not. Full line coverage is expensive, and it does not prove that tests check the right outcomes. A smaller set of strong tests around high-risk behavior can provide better protection than a large set of shallow tests. Coverage can still point to code that no test reaches, so it is useful as a clue. Pair it with questions about user impact, failure modes, and whether a test would catch a realistic defect.
How should teams test AI-powered features?
First, decide what a safe and useful result looks like. If outputs can vary, avoid relying only on exact text matches; test required facts, prohibited content, quality ranges, and behavior across representative prompts. Keep a set of examples for repeat checks, review edge cases with people, and monitor the feature after release. For ordinary code drafted with AI, test its behavior just like code written by a person. The tool used to write it does not change the quality bar.
Final Thought
The QA role is neither dead nor automatically more important because someone added AI to a development tool. Its value depends on whether the work helps a team catch meaningful failures, make sound release decisions, and learn from what goes wrong. Sometimes that means a developer writes a unit test. Sometimes it means a quality engineer finds a risky gap that no one else noticed. Often it means both people stop treating testing as a handoff.
I’ve learned to be wary of claims that promise quality through a single tool, metric, or job title. A green pipeline can hide weak tests. A high coverage number can hide an unsafe flow. An AI-generated script can look neat and still check the wrong thing. Good quality work asks a plain question: what could go wrong for the person using this product, and what evidence would tell us before that happens?
That question is not glamorous. It is a form of care and stewardship: taking responsibility for the work entrusted to a team and respecting the people who rely on it. Build tests that answer real questions, keep human judgment in the loop, and make quality a shared duty. The title may change. The responsibility does not.
— Ermenildo V Castro
FAQPage Schema