From Dev to QA: How I Approached My First Manual Testing Challenge
I’ve spent the last few years as a frontend developer. I’m used to the "building" side of things—making sure buttons look right, APIs connect, and the UI is smooth. But recently, I decided to dive into the world of QA Engineering, and I just completed my first major task: Testing a User Registration Feature.
It sounded simple at first, but it quickly turned into a deep dive into logic and edge cases. Here’s how I tackled it.
1. The Strategy: Looking Beyond the "Happy Path"
As a developer, my first instinct is usually the "Happy Path"—does it work when the user does everything right? In QA, I had to flip that. I started by listing every possible way things could go wrong.
I grouped my scenarios into three buckets:
Positive: Valid data entry and successful redirects.
Negative: What happens if the email is wrong? What if the names have numbers?
Edge Cases: This was the fun part. I tested things like clicking the "Register" button five times really fast or using a password that was exactly 8 characters (the bare minimum).
2. Documenting with Precision
One thing I learned is that in QA, clarity is everything. If a developer can’t reproduce the bug from your report, the report is useless.
I focused on writing structured test cases that were easy to follow. I made sure my "Expected Results" were measurable. Instead of saying "It should work," I wrote "User should be redirected to the /dashboard and receive a confirmation email."
3. The "Gotcha" Moment
The task included a specific bug to report: the system was allowing 7-character passwords even though the requirement said 8-16.
Writing that bug report felt different than just fixing a bug in my own code. I had to assign Severity and Priority. It made me realize that QA isn't just about finding errors; it’s about assessing risk and helping the team decide what needs to be fixed first.
4. Thinking About Security
Finally, I looked at risks that weren't explicitly detailed in the basic requirements but happen all the time in real applications.
I decided to focus on Duplicate Email Registration. The requirements didn't say what should happen if a user tries to sign up with an email that already exists in the database. In a real-world app, if the system doesn't handle this, it could lead to "Account Takeover" risks or broken data. I included a scenario to ensure the system shows a clear error message instead of crashing or creating a second account with the same email. It’s a small detail, but it’s what keeps the user database clean and secure.
Final Thoughts
The biggest lesson? QA is a mindset. It’s not about being the "police" of the codebase; it’s about being a advocate for the user.
I’m excited to move on to Stage 2 (API Testing) and keep building this new muscle. If you’re a dev thinking about learning QA, I highly recommend trying to "break" your own project today. You’ll be surprised at what you find!
