When we talk about Quality Assurance, the traditional approach is straightforward: Does input A lead to output B? But when you put on the hat of a QA engineer, you become professionally paranoid. You don’t just want to verify that input A produces output B. You want to discover what happens when it doesn’t.
Through my experience in both Quality Assurance and Security, I’ve observed something crucial: these two domains are far more intertwined than most realise. When you develop the mindset of breaking things, you’re already halfway to thinking like a security professional.
A Real-World Scenario: The Promo Code Problem
Let me illustrate this with a practical example.
Imagine your system is rolling out a promotional discount code for the holiday season, a one-time code exclusively for customers who’ve been on the platform for over a year.
The Traditional QA Approach
As a QA engineer, you’d start with the happy path:
Verify that only customers with 1+ year tenure are eligible
Confirm the discount applies successfully at checkout for eligible customers
Then you’d test the obvious edge cases:
What happens if a customer tries to apply the same code twice sequentially?
Most systems handle this well, the second attempt gets rejected because the code is already marked as used.
Test passed. Ship it, right?
The Security Lens: Where QA Meets Cybersecurity
Here’s where the security mindset diverges from traditional QA thinking.
The QA question: “Can I apply it twice sequentially?”
System response: No
The Security question: “Can I apply it twice simultaneously?”
System response: Potentially… Yes
This is a race condition vulnerability. If the database read operation (checking whether the code has been used) and the write operation (marking it as used) aren’t properly locked, two parallel requests can both pass the validation check before either one updates the database.
The result? The same promo code gets applied twice, bypassing business logic entirely.
How traditional vs threat driven QA conducts testing.
The Gap Between Quality and Security
Here’s the fundamental difference: QA engineers think like users. Attackers think like adversaries.
Traditional QA follows sequential logic mimicking how a normal user would interact with the system. One action, then the next. If something breaks along that path, we catch it.
But attackers don’t wait for their turn. They don’t follow the script. While we’re testing “What happens when I click this button twice?”, they’re exploiting race conditions, manipulating request timing, and probing the invisible gaps between database operations.
The mindset shift from QA to security isn’t about learning new tools; it’s about questioning the assumptions our tests are built on.
This is where QA engineers with security awareness become invaluable. You’re already testing edge cases and unexpected inputs. The next step is asking: What if those unexpected inputs arrive at unexpected times?