My BA once said, as a joke, that a release wasn't possible if I was on the project.
I wasn't offended. I was kind of proud.
That "break everything" brain is what eventually got me into security. But honestly? The path was messy, unplanned, and involved a lot of figuring things out as I went.
So here's the real story.
I started in QA automation engineer at a startup
My first job was Automation Test Engineer at a startup. They were building a low-code Angular app development platform.
Here's the thing about testing a low-code product - you can't just write a test script and call it a day. You have to actually understand how the thing is built. Otherwise you'll never figure out how to break it.
So I learned development. Not because I wanted to. Because I had no choice.
And once I understood how it was built? I went a little crazy finding bugs. Weird scenarios. Random edge cases. Things nobody thought to test. Developers would find my Jira tickets and just... sigh.
But the bugs were real. Every single one.
Then came the pentest report that changed everything
At some point our app went through a third-party penetration test.
When the report came back, I got assigned to retest the findings - basically check if the developers had actually fixed the vulnerabilities or just closed the tickets.
Someone pointed me to Burp Suite, handed me the report, and said figure it out.
I had zero formal security training. I didn't really know what I was doing. But I opened the tool, followed the report, and started going through each finding one by one.
And something felt different.
It wasn't the same buzz as finding a weird UI bug. This was more serious. These were real vulnerabilities. Real risks. Real impact if someone exploited them.
I got hooked. Not in a fun way. In a "I need to understand this properly" way.
I started a PG in Information Security. Told almost nobody.
It wasn't a career move. It was just curiosity.
I enrolled in a part-time postgraduate program in Information Security and studied on weekends while working full-time during the week. No big announcement. No LinkedIn post about it. Just me, my laptop, and weekend mornings that could've been spent sleeping.
The four day leave that accidentally changed my career
I joined a Canadian broadcasting SaaS company as an Automation Test Engineer. UI automation first, then API automation when they needed someone there.
Security was not part of my job description.
I had mentioned in my leave request that I was taking time off for exams. My QA manager noticed it and casually asked which exam.I told him - my PG, Information Security.
He went quiet for a second.
After the exam he came back to me and asked if I'd be interested in doing a POC - go find real security issues in our SaaS application. He'd been trying to get a security function off the ground for a while and hadn't managed it yet.
I said yes immediately.
Internally I was thinking - okay, I need to figure a lot of this out.
The POC was nothing like testing bugs in QA
In QA finding a weird bug felt exciting. Like a little win.
This was different.
I was pulling from everything I had - my pentest retesting experience, my PG, OWASP docs, Udemy courses, whatever I could find online. Because I knew this wasn't just for me. I'd be presenting these findings to developers and management in show and tell sessions. Raising Jira tickets. Running security awareness sessions.
You can't show up with something half-baked
So I researched properly. Made sure every finding was real, exploitable, and clearly explained. And I did find real vulnerabilities. Documented everything. Presented it all.
What started as a POC quietly became my full time job.
Eventually it became official. The title changed to Security Engineer.
From that point I moved out of QA completely and worked directly with the development teams on security full time.
I wasn't done studying though
Once I was properly in security I went back to studying. Masters in Information Security - part-time, while working full-time. Weekends. Late nights. No sabbatical. Just got it done.
After the Masters I did my CEH. Not to impress anyone. I wanted a structured framework for what I was already doing every day and make sure I wasn't missing anything.
The progression in hindsight: PG to get curious. Hands-on to get real. Masters to go deeper. CEH to fill the gaps.
None of it felt like a plan at the time. Just the next thing I needed to do.
And I'm still going. Currently studying for the AWS Security Specialty certification. There's always something next.
What the job actually looks like now
Today I work on a cloud-native SaaS broadcasting platform - 80+ serverless microservices on AWS. Very different world from Burp Suite and pentest reports
My day to day looks like triaging AWS Security Hub and Access Analyzer findings, keeping track of vulnerable dependency updates to meet SLAs, building GitHub Actions workflows to automate security tasks, preparing SOC 2 audit evidence, implementing supply chain security controls, and a lot more that I didn't even know existed when I was in QA
Going from web app security to cloud security was a whole new learning curve. But the core mindset was the same - understand the system well enough to know exactly how it can fail.
Things I wish someone had told me
Your QA brain is actually a superpower. Thinking in edge cases, weird scenarios, "what if someone does THIS" - that's security thinking. Don't undersell it in interviews.
You don't need a perfect plan. My entire career pivot happened because of a four day leave request. Curiosity and showing up consistently matter more than having a roadmap.
The mindset shift is real. Breaking things in QA is fun. Breaking things as a security engineer is responsibility. When your findings have real consequences you slow down, research properly, and make sure you're right.
Do the credentials while you're in the role. Having real context makes the studying actually stick. Theory alone doesn't prepare you for anything.
If you're in QA and thinking about making this move
Honestly you're already closer than you think.
You break software for a living. You think adversarially. You document findings. You communicate issues clearly to developers.
That's literally the job.
You don't need to wait until you feel ready. Pick up OWASP, try a bug bounty, spin up a personal AWS account and intentionally break something. See how it feels.
The path doesn't have to be planned. Mine definitely wasn't.
Are you in QA or SDET and thinking about moving into security? Or already made the switch? Drop your story in the comments - would love to hear it.
Top comments (0)