Roles & Strategy

Test automation is a technical subject with an organisational failure mode. The most common way for a test strategy to fail is not a bad framework choice; it is nobody being clear about who owns what, and the automation quietly becoming one person's job on a team of twelve.

#Three roles that are genuinely different

SDET, automation tester and manual QA are not seniority levels of the same job, though they are frequently advertised that way.

An SDET is a software engineer whose product is testability: harnesses, fixtures, data tooling, CI infrastructure, and changes to the application that make it possible to test. They write production code.

An automation tester writes and maintains the tests themselves. The skill is knowing what is worth automating and expressing it so it survives — which is a different skill from building the machinery.

Manual QA — better called exploratory testing — is the only one of the three that can find a problem nobody thought to look for. Automation checks known expectations. It cannot be surprised. A team with excellent automation and no exploratory testing ships confidently and is regularly astonished.

#The strategy questions

Test strategy is the deliberately unfashionable page: what are we actually trying to prevent, what does each kind of test cost us, and what are we choosing not to test. Most teams have an implicit strategy that amounts to "write tests for the things that are easy to write tests for", and it shows in the shape of the pyramid.

Shift left is the idea that quality work moves earlier — into design, into the pull request, into the developer's inner loop. It is largely right and frequently used as a slogan for making developers do QA's job with none of the tooling.

Quality ownership is the question underneath all of it: when a defect reaches production, whose failure is it? There is one answer that works and several that feel better.