Software tester / QA engineer
Finds out how the software fails before users do — and is the person who says whether it is ready to ship.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for manual testers and test-automation engineers on product software teams. Safety-critical certification testing (medical, automotive, aviation) and games QA differ.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Manual regression testing
Automating≈ Platform inferenceClicking through the same flows every release to confirm nothing that used to work has broken.
Scripted regression was already automatable; what changed is that agents can now operate a real interface from a plain-language description and repair their own scripts when the interface changes, which removed the maintenance burden that kept teams on manual testing. This is the largest block of hours in most QA roles and it is going quickly.
Writing test cases and automation
Automating✓ Evidence-backedTurning requirements into cases, and cases into scripts that run in the pipeline.
Generating tests from a specification or from the code itself is one of the most effective uses of code-generation tools, and coverage that would have taken a sprint now appears in an afternoon. The generated tests are shallow in the same way generated code is — they confirm what the code does rather than what it should — which is why the next task matters more.
Exploratory and adversarial testing
Still human-led≈ Platform inferenceTrying the thing nobody specified: the weird input, the race, the user who does step 3 before step 2.
Generated tests derive from the specification or the code, so they share its blind spots. Finding the failure nobody imagined requires a model of how real users and real systems misbehave, built from experience with this product and this domain. Tools widen the search; the hypothesis about where to look is still human, and it is where the expensive bugs are.
Deciding whether it ships
Still human-led≈ Platform inferenceWeighing the open bugs, the risk, the deadline and the business, and saying yes or no.
This is an accountability decision with organisational consequences, and teams have not shown any wish to delegate it. Dashboards summarise the state; the call about what level of risk this release, this customer base and this week can bear is made by a person whose judgement the team trusts.
Testing systems with a model inside
New task≈ Platform inferenceEvaluating software whose output is not deterministic — building evaluation sets, catching regressions in behaviour, testing for harmful outputs.
Most new products have a model in the loop and cannot be tested by asserting a fixed output. Evaluation design, adversarial prompting and behavioural regression are a new discipline with few practitioners, and the QA mindset — assume it is broken, find out how — transfers directly.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
● 1 verified event for this occupation, plotted at the date it happened — the parts of the line near a marker are anchored to something checkable.
Scripted regression was automatable long before 2022, so the baseline is high. The bend is at the 2024 H2 / 2025 H1 pair, and it is specifically about computer use: agents that operate a real interface from a plain-language description removed the script-maintenance burden that had kept teams doing it by hand.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
One company, improvement of existing unit-test classes with build/pass/coverage filters; 75% of generated cases built, 57% passed reliably, 25% added coverage. Company-authored paper; a time-boxed test-a-thon setting rather than routine pipeline use.
Small-scale trial in a real setting. Tells us the deployment conditions are being tested, not that they hold.
Meta — industry paper (arXiv 2402.09171, FSE 2024) ↗What this means for you#
Entering as a manual tester is the weakest entry on this site, because that is the task going fastest. Enter instead through the adversarial mindset and the new discipline: learn to break things nobody specified, and learn to evaluate model-based systems, where there is almost no one with experience and teams are hiring. Being able to write code is now a baseline for the role rather than a specialism within it.
If your week is mostly regression and script maintenance, the role is being consolidated under you and you should move before it moves you. Your real asset is the model in your head of how this product breaks; turn it into exploratory testing, release judgement and evaluation of the model-based features your team is almost certainly adding. Those are senior positions, and they are being filled by whoever claims them first.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
From executing tests to owning quality
Someone has to decide what 'tested enough' means, hold the release decision and own the exploratory work. That role survives; the execution role does not.
Requires the team to accept a tester's no, which depends on credibility you have to have already built.
Find one bug this week that no existing test or generated test would have caught, and write up how you thought of it. That write-up is your job description.
Specialise in evaluating model-based systems
It is new, scarce and directly adjacent to what testers already do. Teams shipping model features need someone who assumes they are broken.
Requires statistics you may not have, comfort with non-deterministic pass/fail, and tooling that is still immature.
Take one model-backed feature in your product and write twenty inputs designed to make it fail or misbehave. Run them. Report what you found the way you would report any bug.
Developer-in-test or platform engineering
Building the pipelines, environments and tooling that let the whole team test is engineering work in steady demand, and it uses a tester's knowledge of what goes wrong.
It is a software engineering role and will be judged as one; expect to be tested on code.
Pick one flaky part of your team's test pipeline and fix it properly. If you enjoyed that more than finding the bug, the path is real.
Common questions#
Manual test execution is, and quickly. Quality as a discipline is not: someone still has to imagine how the system fails, decide whether it is ready, and — increasingly — evaluate software whose behaviour is not deterministic, which almost nobody knows how to do yet. The job is moving from executing tests to owning risk, and from asserting fixed outputs to evaluating behaviour. People who make that move are more valuable than testers were; people who do not will find the role consolidated around them.
Method and sources#
- Assessment date
- 2026-09-10
- Basis of the task judgements
- 1 evidence-backed · 4 platform inference · 0 not enough evidence
- Verified events
- 1