There is a version of the QA Engineer role that survives in a lot of organisations: the person at the end of the pipeline who receives the build, clicks through it, and files what is broken. Testing as inspection. Quality as a gate applied after the fact.
It is a real job. It is also the least valuable configuration of the role, because by the time the build exists, every expensive decision has already been made.
The higher-value version starts much earlier and asks a different question. Not "does this work", but "what evidence would convince us this requirement has been met, and what evidence would convince us it has not".
The job is designing evidence
A requirement says the system should do something. A test is a claim that if you do X, Y will happen. Test design is the work of choosing which claims are worth making.
That choice is where the skill lives, because you cannot test everything and the combinations grow faster than any team can cover. A QA Engineer picks the subset that carries the most information about whether the requirement holds.
- The path everyone assumed. Fast to write, low information. It usually works.
- The paths nobody discussed. Empty inputs, maximum inputs, expired sessions, partial data, the second click before the first finished. This is where defects actually live.
- The boundaries. If a rule applies below fifty thousand rows, the interesting values are 49999, 50000, and 50001. Not 100.
- The failures. What the system does when the thing it depends on is unavailable. Rarely specified, always eventually exercised in production.
Testing the requirement, not the build
This is the difference between the two versions of the role, and it is worth being precise about.
If test cases are written from the finished screen, they encode whatever the developer assumed. When the developer misread the requirement, the tests confirm the misreading. Everything passes. The defect ships anyway and gets found by a user.
If test cases are written from the requirement, they are independent evidence. A failing test then means one of two useful things: the build is wrong, or the requirement was ambiguous enough that two people read it differently. Both are worth knowing, and the second is worth more, because it is a defect in the specification that would otherwise have propagated into every downstream artefact.
Questions. A QA Engineer reading a requirement before development starts will find ambiguities the author cannot see, because the author knows what they meant. Every one of those found before build is a defect that never existed.
Severity is not priority
These get conflated constantly, and the conflation makes triage meetings longer than they need to be.
| Question it answers | Who owns it | |
|---|---|---|
| Severity | How badly does the system misbehave? | QA Engineer |
| Priority | How soon must we fix it? | Product Owner |
A cosmetic misalignment on the checkout button is low severity and can be high priority. A total failure in a feature three people use is high severity and can be low priority. Keeping the two separate lets each be decided by the person who actually has the information.
Key takeaways
- Test design is the work of choosing which claims about the system are worth making.
- Tests written from the build inherit the build's mistakes, tests written from the requirement are independent evidence.
- The most valuable QA output before development is questions, not cases.
- Severity is a QA judgement, priority is a Product Owner decision, and conflating them slows triage.
What QA owes the other three roles
To the Business Analyst: early feedback on whether a requirement can be tested at all. If coverage cannot be designed from it, the requirement is not finished, and saying so during refinement costs minutes rather than weeks.
To the Product Owner: an honest read on risk. Not "we found twelve defects", but "the payment path has thin coverage and that is where the money is".
To the Delivery Manager: a readiness signal that means something. Coverage against acceptance criteria, open defects by severity, and what is genuinely untested. A number nobody can interpret is worse than no number.
Where the role is heading
Automation changed which parts of the job are manual, not what the job is. Generation tools change it again: a first draft of a suite can now be produced in minutes. Neither removes the part that matters, which is judgement about what is worth verifying and whether the evidence is sufficient.
A generated test case is a proposal. Deciding whether it is the right proposal is the role, and it always was.