A developer opens a pull request. The code looks fine. The unit tests pass. The build is green.
Then, somewhere in the middle of a much larger test run, a login test fails.
The first question is usually: Is this a bug?
Sometimes it is. Sometimes the test is flaky. Sometimes the API is returning something unexpected. Sometimes the database contains bad data. And sometimes the test has been broken for three weeks and nobody noticed because everyone learned to ignore the red mark.
That small situation says a lot about where QA is moving.
Testing software is still the job. But modern QA increasingly requires understanding why something failed, where it failed, how confidently we can release it, and what the engineering team can change so the same class of problem is less likely to happen again.
That is the shift toward Quality Engineering.
QA Used to Arrive Near the End
The traditional software development cycle was easy to picture.
Developers wrote the code. QA received a build. Testers worked through requirements, found defects, sent them back, and tested the fixes. Eventually, someone decided the product was ready to ship.
There is nothing inherently wrong with that model. For many teams, it worked well enough.
The problem is that software delivery has changed.
Applications are rarely one piece of software anymore. A single user action can involve a browser, frontend code, several APIs, authentication services, databases, and third-party systems. Teams may merge code several times a day. Automated pipelines can build and deploy changes before someone has had time to manually walk through every important scenario.
And now there is another variable: AI can produce working code very quickly.
That makes one old assumption difficult to maintain: that quality can be an afterthought.
If a defect comes from a misunderstanding in the requirement, a problem in the API contract, or an incorrect database assumption, discovering it after the feature has been built is expensive.
Quality Engineering moves some of that thinking earlier.
The QA engineer needs to understand the requirement before writing the test. They need to understand the system before deciding where to test it. They need to think about risk before deciding what to automate.
In other words, the job starts before the test case does.
The Biggest Change Is Not Automation
If we ask someone what a modern QA engineer needs to know, the answer will often start with automation.
Playwright. Selenium. APIs. CI/CD. Frameworks.
All useful. None of them, by themselves, make someone a good quality engineer.
A large test suite can create a false sense of security.
Imagine a team with 2,000 automated UI tests. They run for two hours. Twenty tests fail because of timing issues. Ten fail because test data was shared between environments. Three are genuine product defects.
If the team spends most of its time rerunning the suite until it turns green, the number 2,000 doesn’t mean much.
This is why test engineering is partly an exercise in judgment.
Modern automation training increasingly reflects this. A developer-capable approach starts with programming fundamentals, test design, and debugging before moving into Playwright, API testing, framework design, and CI/CD.
The aim is not to create someone who can produce more test scripts.
It is to create someone who understands what those scripts are supposed to prove.
A Screen Is Only the Part of the System You Can See
One of the easiest traps in QA is treating the interface as the whole product.
Consider a login page.
A tester enters a username and password, clicks Login, and gets an error.
You could stay on the screen and try the scenario again.
Or you could start asking better questions. Those questions require a different kind of technical understanding.
They don’t mean every QA engineer needs to become a backend developer. They do mean that being comfortable reading code, working with APIs, querying data, and navigating a codebase can dramatically improve the quality of an investigation.
This is one reason developer-capable QA engineers are becoming more useful to engineering teams.
Once you’ve built part of a system, an error message on the screen stops being the end of the story. You have some idea of what is happening underneath it.
Tests Have to Live Where the Software Lives
There was a time when it was perfectly normal for much of QA to happen on a tester’s machine.
That becomes difficult when the rest of the engineering organisation works through Git and automated delivery pipelines.
If a pull request can change production behaviour, quality checks need to be part of that same workflow.
A sensible pipeline might run a small smoke suite when a pull request is opened. A broader regression suite can run after merging. A full cross-browser or larger regression run might happen overnight.
The important thing is that the checks have a purpose at each stage rather than making every change wait for every test.
That changes the meaning of a test failure.
It isn’t just a report waiting for someone in QA to read.
It is now part of the release decision.
And that creates a responsibility for the QA engineer that is easy to overlook: the pipeline itself needs to be trustworthy.
A flaky test is not harmless because it is “only a test.” If people stop believing the pipeline, the quality gate has already failed.
AI Makes Judgment More Important
AI is going to make some parts of QA work considerably faster.
It can generate test scenarios. It can produce test data. It can draft Playwright code. It can help summarise failures and suggest possible causes.
That is useful.
But there is a difference between generating a test and deciding that the test is worth having.
The machine can generate possibilities. Someone still has to decide which possibilities matter.
When producing test code becomes cheaper, deciding what deserves to be tested becomes more valuable.
That is a skill AI does not remove. It makes more visible.
Quality Stops Belonging to One Person
Quality Engineering also changes the boundaries between roles.
A developer who understands how a feature will be tested is more likely to think about testability while building it.
A QA engineer who understands Git, pull requests, and CI/CD can participate in the engineering workflow rather than waiting for a build to arrive.
A product manager who can explain the highest-risk user journeys gives the team something much more useful than a long list of generic acceptance criteria.
The difference is that quality is no longer treated as something that can be handed from one department to another.
Quality Engineering looks at the chain, not just the final bug.
QA Isn’t Disappearing. The Job Is Getting Wider.
There is sometimes a fear that automation and AI will make QA less necessary.
Machines are getting better at executing predefined checks. AI is getting better at producing code and test ideas.
That makes human testing judgment more important, not less.
Someone still needs to notice that the requirement doesn’t make sense.
Someone needs to wonder why a feature works for an administrator but fails for a normal user.
Someone needs to recognise that a green pipeline doesn’t necessarily mean a safe release.
Someone needs to decide whether a failure is a product defect, a test defect, or an environmental problem.
The QA engineer of the future may spend less time clicking through repetitive regression scenarios and more time understanding systems, designing coverage, investigating failures, improving automation, and collaborating with engineering teams.
That is a meaningful change in the role.
But it isn’t the death of QA.
It is QA growing up.
Final Thoughts
The best quality engineers will still have the instincts of good testers. They will be curious about edge cases, notice things others miss, and think about what real users might do beyond the happy path.
They will simply have more technical tools at their disposal.
The goal isn’t to test everything. It is to know what matters, understand where it can fail, and build enough confidence into the engineering process that problems are found while they are still inexpensive to fix.
That is Quality Engineering.
And the title may still say QA. The work will increasingly look like engineering.
