The five QA roles, and which problem each one solves
Most disappointing engagements are a hiring mismatch, not a quality problem. The team asked for "more QA", got a capable person, and found six weeks later that the capable person does not work at the layer that was failing.
Five roles sit under the QA label, and only two of them write test automation. They command different rates, they own different layers, and they fail in different ways.
Manual and exploratory tester
Finds what scripts miss. They work from risk and curiosity rather than a written case, which is exactly why automation cannot replace them.
Hire when: requirements are unclear, the feature is new, or your defects are found by customers rather than by tests.
Cannot fix: a regression suite that takes four days. Exploratory work does not scale by repetition.
Automation engineer or SDET
Writes and maintains the test automation suite. Most of the job is maintenance rather than authoring, and that distinction matters when you screen them. Test automation rewards the engineer who deletes as readily as they add.
Hire when: regression testing has outgrown the team, or releases slip because nobody can verify them quickly enough.
Cannot fix: a codebase with no seams to test against. If everything runs through the UI, automation will be slow and brittle whoever writes it.
Automation architect
Chooses the test automation framework, the layering and the standards. Decides what gets tested at unit level, at API level and at end-to-end level, then makes those choices hold across teams.
Hire when: the suite is flaky, slow, or three teams have built three incompatible frameworks.
Cannot fix: a shortage of hands. An architect who spends their time writing test cases is an expensive test writer.
Performance and load engineer
Owns non-functional requirements: throughput, latency, capacity under a scale event. Different tooling, different mindset, rarely the same person as your functional automation engineer.
Hire when: you have a launch, a seasonal peak, or a customer contract with numbers in it.
Cannot fix: functional defects. A fast, wrong answer is still wrong.
Release and environment specialist
Owns test data, environments and the pipelines that run the suite. This is the role buyers forget and then urgently need, because a test suite with no reliable environment produces noise rather than signal.
Hire when: tests pass locally and fail in CI, or your team spends more time fixing environments than testing.
Cannot fix: test design. They make the suite runnable, not correct.
Work out which layer is failing before you write the job description. The answer is usually narrower than "we need more QA", and the narrower answer is cheaper.
