LO
Software tester / QA engineer — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
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.
This is explicitly the largest block of hours in most QA roles. Nothing in the remaining tasks is large enough to absorb the people whose week it filled.
Writing test cases and automation
Automating≈ Platform inferenceTurning 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.
Generated tests confirm what the code does rather than what it should. Teams that measure coverage rather than defects will conclude this task is solved, which is a measurement problem that hurts testers.
Exploratory and adversarial testing
Still human-led✓ Evidence-backedTrying 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.
The hypothesis about where to look is built by having done the regression work that is disappearing. This task is protected by experience that the pipeline no longer produces.
Deciding whether it ships
Still human-led✓ Evidence-backedWeighing 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.
On many teams this call belongs to an engineering manager, not a tester. Where it does, protecting it protects someone else's job.
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.
Few practitioners is a statement about now. The discipline is young enough that its eventual size is unknown, and it may end up inside the model teams rather than in QA.