QA Engineer

Teams used to employ someone to do the checking by hand: take the list the evening before a release, click through the screens in order, write down what looks wrong. With twenty features that is entirely sufficient, and cheaper than any alternative.

It's the first thing to collapse as features accumulate. The list of checks grows with the feature count while the hours available to walk it do not, and nothing about the growth is gradual. At 200 items a full pass takes two days, and on a team that deploys twice a week the checking becomes longer than the release cycle. From there people start shrinking the list, and the gaps they cut come back as incidents a quarter later, by which point nobody connects the two.

A QA engineer exists to move that checking from a person into code. Instead of clicking the same things every time, the clicking gets written as code that runs on every release by itself, at whatever hour the release happens. What defines the seat is that it builds the verification system rather than performing the verification, which is a different job with a different output.

A day goes into reading what ran overnight, writing the check list for whatever is being built, and moving those checks into code.

1. Read the results from the overnight run. Sort the failures into two piles: real defects, and flaky tests that pass and fail on identical code. Left alone, the second pile teaches everyone on the team to ignore failure alerts, so this sorting is the first job of the day. Twenty failures where seventeen are flaky means the other three get ignored too.
2. Write the check list for the feature in progress. The builder already walks the normal path, so what gets written here is mostly boundaries and failure paths: an empty value, an account without permission, a connection dropped midway. Inputs nobody anticipates — an emoji in a user's name, a document title 400 characters long — come from here too.
3. Move checks into code. End-to-end tests drive a browser through the steps a user takes, and only paths checked often and likely to survive get moved. Automate a screen whose wording changes monthly and all the time goes into maintaining that test instead of writing new ones. Signup and payment, unchanged in shape for years, go first, and the newest screen on the product usually goes last.
4. File findings and follow them. Reproduction steps, expected behavior, actual behavior, and a severity — the size of the impact on the service. An entry with no reproduction steps doesn't get fixed; it just stays on the list until someone closes it unread. Writing down what was pressed and what appeared, in order and with nothing assumed, is the basic craft of this seat.
5. Review the system weekly. Check test coverage, the share of code the tests touch, and look back at last week's incidents to work out which list that path should have been on and was not.

Unlike building, this seat has a hard time making success visible. Done well, nothing happens; done poorly, it shows up as an incident. So the work gets read through the hours checking takes and the change in incident count rather than through a tally of things prevented, which nobody can produce anyway.

The closest counterpart is the developers. Asking about boundary conditions, narrowing down where a failing test actually broke, agreeing what counts as expected behavior. Writing the reproduction steps belongs here and finding the cause belongs there, and the more precise the steps the shorter the second half becomes.

With the product manager who wrote the requirement, the first entries of the check list get agreed. Without knowing where this round's scope ends, there's no way to separate a defect from something that was simply never in scope, and filing the second kind wastes everyone's afternoon. With the designer, the review of whether the build matches the design gets divided up so neither side checks it twice.

The deployment side is another counterpart. Attaching the written tests so they run inside the deployment pipeline is decided jointly: which failures stop a release and which only raise an alert. Set everything to stop and one flaky test halts the whole team; set nothing to stop and the pipeline becomes decoration.

Support shows up after an incident. Recreating what the user experienced is where cause-finding starts, and once it reproduces reliably, the same item joins the check list for good. That path — one support ticket becoming one line on a permanent list — runs through this seat every time.

"That failure is flaky. It breaks about one run in three."

A verdict that the test is unstable rather than the code being defective.

"This path gets checked often enough to be worth automating."

Dividing what a person looks at from what should run by itself from now on.

"Without reproduction steps I can't fix it."

Filing something alone doesn't hand the work over to anybody.

The seat was created at Pagedeck the quarter the check list reached 210 items. Theo was spending two days before every release on checking, and those two days were eating the time he had for building anything new.

What the new hire did in the first two months was move the list into code. Sixty of the 210 items, covering signup, payment and sharing, became tests that run on every deploy, and the rest stayed as a list a person walks. Pre-release checking went from two days to three hours over that period. The shorter human list also got read more carefully, which was a second gain from the same change.

The most common mistake is treating it as the seat for people who can't build. The visible part is clicking through screens, which invites that reading. But most of what this seat produces is code: tests that drive a browser, the wiring that runs them in the pipeline, fixes for the unstable ones. Organizations that judge the seat by its manual half never get the automation done, and the checking hours keep climbing until someone proposes checking less.

Believing responsibility for quality sits here is the other one. Quality is in the name, so the assumption is natural. But all this seat can do is find what's wrong in something already built. Where the question after an incident is why QA didn't catch it, lists grow defensively and releases slow down. The question worth asking is why that path wasn't on the list at all, and the answer usually lives further upstream, in how the requirement was written or how the thing was designed.