I Was a Manual Tester Who Handled HackerOne Tickets

My job title said QA Engineer. The actual work, on more than one occasion, involved triaging vulnerability disclosures from external security researchers, writing reproduction steps for reported exploits, and coordinating with developers on fixes for issues submitted through HackerOne. The QA Engineer job title vs actual work gap was significant. Nobody hired me for that work. Nobody trained me for it. It became part of the job because it needed to be done and I was the person on the team who understood the systems well enough to do it.

This is not an unusual story. Ask enough QA engineers what their day actually looks like and you will find a gap between title and work that ranges from mildly funny to genuinely absurd. The gap is not random noise, it follows a pattern that is worth naming.

What the Title Says

QA Engineer. Software Test Engineer. SDET. Quality Analyst. The specific label varies but the implied scope is consistent: write tests, run tests, find bugs, report bugs. Maintain the test suite. Review requirements documents. The role has a defined position in the org chart between the engineers who build and the product managers who decide. The scope is bounded.

That is the job on paper.

What the Work Actually Was

The gap between job description and actual work follows the same logic across companies and teams. QA engineers are the people who understand how a system behaves under conditions the original developers did not plan for. That understanding makes them the right person for tasks that were never written into any job description.

Security researchers submitting HackerOne tickets write reproduction steps, but those steps assume a level of system familiarity that a developer triaging the ticket may not have. A QA engineer who has spent months finding ways to break the system has that familiarity. The work becomes a natural handoff even when the org chart never accounted for it.

The same logic produces the same outcome in other areas. Production incident investigation, because the QA engineer has the best mental model of what the system should be doing. API documentation that reflects how the system actually behaves rather than how it was spec’d, because the QA engineer has run into all the gaps. Performance testing that started as a one-off request and quietly became a standing process. Accessibility reviews that nobody else on the team was positioned to run. None of these are QA in the narrow functional sense. All of them are things QA engineers end up doing.

Why This Matters for Career Framing

The gap between title and actual work is a career problem when it stays invisible. Experience that never gets named does not appear on a resume in a way that transfers. It does not get recognized in a performance review as something beyond baseline expectations. It does not qualify you for the next role in any legible way.

The work I did on HackerOne tickets was security triage. The work that got me in the room for those tickets, months of breaking the system in ways nobody else thought to try was security-informed QA. Calling it “QA stuff” in a resume bullet does nothing. Calling it security triage with HackerOne and linking it to the outcomes it produced a number of issues resolved, severity levels handled, process improvements that came out of it changes what roles it qualifies for and what conversations it opens.

The post on Security QA Without the Security Title is the technical side of this same argument, what the specific practices look like and how to recognize them in your own work. This post is the career framing side: the practices are there, the title is not the ceiling.

The Label Is a Starting Point

QA Engineer is a starting point, not a definition of scope. The engineers who grow fastest in this field are not the ones who ran the most test cases on schedule they are the ones who noticed what was falling through the cracks and picked it up. HackerOne tickets falling through. Documentation falling through. Performance baselines that nobody was tracking. Accessibility work that kept getting deprioritized.

The job title does not expand to cover the work. The work expands regardless of the title. Paying attention to what the work actually is and building language for it is the practical skill that makes the rest of the career trajectory legible.