People are surprised that I do both QA and security. To me they've always felt like the same instinct pointed at different targets. The skills transfer almost directly.
Both Are About Breaking Assumptions
A developer builds for the happy path. A QA engineer asks "what if the input is empty / huge / wrong type?" A security tester asks "what if the input is malicious?" Same muscle — refusing to assume the user behaves — just a different threat model.
The Negative-Testing Mindset
QA taught me to test what shouldn't happen:
- What if I submit this form twice?
- What if I skip a required step?
- What if I send a value the UI never offers?
That last question is one keystroke from security testing. "The UI only offers options A and B" becomes "what if I send option C the server didn't expect?"
What QA Already Gives You
| QA skill | Security application |
| Boundary testing | Buffer/overflow edge cases |
| Input validation testing | Injection (SQL, XSS) |
| Auth/role testing | Broken access control, IDOR |
| Reading network traffic | Intercepting and modifying requests |
| Reproducible bug reports | Writing clear vulnerability reports |
The New Muscle to Build
The genuinely new part is thinking like an attacker — chaining small issues into real impact, and understanding why a flaw is exploitable, not just that it's wrong. QA stops at "this behaves incorrectly." Security continues to "and here's how someone abuses it."
You Don't Have to Choose
The best testers I know carry both. A QA engineer who understands security writes better test cases. A security tester who thinks like QA writes clearer reports and finds the boring-but-critical bugs scanners miss. The overlap is the advantage — lean into it rather than picking a side.