Software tester / QA engineer

A paper by Uber engineers about a system running in Uber's own pipelines. It says DragonCrawl achieves a 91.6% pass rate on iOS and 92.2% on Android across 1,013 automated tests running continuously in CI/CD, cut test onboarding from 96–120 hours to under 4, and saved an estimated 27 developer years of test maintenance; the test engineers who used to execute scripts were repositioned as 'Context Engineers' rather than 'Clickers', and Uber says it achieved scalable quality assurance without proportional headcount growth. The time savings are Uber's own estimates, and it covers mobile end-to-end tests at one company.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

Self-reported survey of 200 senior engineers at large US, UK and EU enterprises — and the report is published by Lightrun, which sells debugging tools, so the finding and the product point the same way. The Amazon outages it cites (2 and 5 March 2026, traced to AI-assisted changes deployed without approval, followed by a 90-day code safety reset across 335 systems) are independently reported events; the percentages are not. Enterprise software only.

Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.

A paper by Meta staff about test generation in Meta's own engineering. It says mutation-guided LLM-based hardening test generation is already deployed in Meta's continuous integration system, that the earlier coverage-based generator has been deployed and regularly evolved at Meta for two years, that it analysed 22,126 generated tests across catching and hardening workflows, and that in a manual study of 600 diffs with weak catches, rule-based and LLM assessors cut human review load by about 70%. The authors say the catching workflows themselves were deployed mainly to collect data, and the paper gives inconsistent counts of confirmed catches; Meta builds these tools for its own use.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

A peer-reviewed experience paper by university and ByteDance authors about a tool deployed at a large consumer internet company. It says API regression tests for cross-service business flows are still largely built and maintained by QA engineers, and that in a nine-month production deployment starting in March 2025 the tool generated 3,196 test cases with an overall code adoption rate of 85.4%. Adoption varied widely by business line; the authors built the tool and measured its adoption themselves.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

A federal memorandum binding US executive agencies. Among the minimum risk management practices for high-impact AI, agencies must develop pre-deployment testing and risk mitigation plans reflecting expected real-world outcomes; where they cannot access the source code, models or data, they must use alternative test methods such as querying the AI service and observing outputs or providing evaluation data to the vendor; and they must conduct testing and periodic human review of AI use cases where feasible after deployment. It binds agencies, not testers by name, and covers high-impact uses only.

Regulation, subsidy or public procurement is requiring or funding adoption — the mirror of a constraint. It shows adoption is being required, not that it has happened, so one mandate is never enough on its own; two independent ones are.

A paper by Microsoft's AI Red Team about its own work testing generative AI products for safety and security failures. It says that as of October 2024 the team had conducted over 80 operations covering more than 100 products, that the volume made fully manual testing impractical so it built automation, and that such tools should not be used with the intention of taking the human out of the loop, since prioritising risks, designing attacks and defining new categories of harm need human judgement. This is a dedicated red team rather than product QA, and Microsoft sells the models and promotes its open-source tool.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

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 — so one pilot is never enough on its own; two independent ones are.

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.

Reshape the role

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.

Reshape the role

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.

Adjacent move

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.

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.

The signal is who writes the regression suite on your team this quarter. When the suite is generated and repairs itself after an interface change, the block of hours that funded most QA roles is gone — that is the specific capability that moved, and you will see it in your own repository before you see it in any report.

Manual regression and test-case writing — the two marked automating, and manual regression alone is the largest block of hours in most QA roles. Exploratory testing and the ship decision are not, but neither is large enough to absorb the people whose week the regression filled.

It is a genuine and growing discipline — evaluation sets, behavioural regression, adversarial prompting — and the QA mindset transfers directly. The honest caveat is that it is young enough that nobody knows its eventual size, and it may end up staffed inside model teams rather than in QA.