I began my journey as a QA engineer four years ago, never imagining I’d end up in testing. Back in college, I aspired to be a system analyst, but here I am now — hehehe!
While I may not have decades of experience, I’ve gathered enough insight to share on what it takes to Succeed in Quality Assurance, especially if you’re considering a career in this field.
In this piece, I’ll discuss four things you should know before transitioning to quality assurance. We’ll discuss the difference between a QA and a Tester so you know what you’re getting into. Why you should learn automation, the importance of communication, and how you should test features if you do decide to take this path.
Let’s start with the first.
Many people (myself included, at first) mistakenly think that a QA engineer is the same as a tester. This is far from the truth.
While testing is part of a QA engineer’s daily activities, quality assurance encompasses far more that just testing. Being a QA means that you’re responsible for ensuring the overall quality of the product in your organization, not just testing. QA is also about processes, which include procedures, people, and tools. As a QA, you should naturally be more critical than a tester. If something seems off, you don’t hesitate to raise concerns, you ask questions, and challenge assumptions.
Here’s an example of a task a QA would that on that a tester wouldn’t. In my current organization, my manager assigned me a task to evaluate our entire SDLC process so that we could achieve better QA results.
As QAs that sometimes the root cause of defects in product lies in the development processes and so by examining and improving these processes, we can reduce the likelihood of defects and enhance our overall quality.
I’ve often heard people say that automation is just about tools. While it’s true that critical thinking and the ability to analyze a product to generate a comprehensive list of test cases are crucial, that doesn’t excuse you from learning about automation.
Trust me, when companies need scalability and flexibility in testing, automation is incredibly useful. Acquiring these skills makes you a valuable asset to any organization.
To prove this, all the companies I’ve worked for use automation testing and continuously invest in optimizing it. However, the emphasis shouldn’t be solely on the tools but on these tools align with the company’s specific needs. For instance, one company I worked with used Katalon to support both mobile and web platforms, while others found success with simpler tools like Playwright and Selenium. So in addition to learning automation, you would also need to learn how to choose the tool that fits your use case.
If you’re uncertain about where to start learning automation, I suggest starting with minimal-code or even no-code automation tools, like Selenium IDE. Once you’re confident, you can explore other automation tools that require small to medium coding skills.
The longer I work as a QA, the more I realize that over 50% of a QA engineer’s activity revolves around communication. Don’t believe me? Let’s break it down. These are your typical activities as a QA:
And these are only few of them. To be successful in QA, You need to understanding who you’re speaking with, what you want to convey, and communicate effectively.
We can’t expect everyone to be practical and professional all the time. After all, we’re all human, and sometimes our moods can influence our interactions.
If after reading the previous three points, you still want to become a QA, here’s a head start on testing features in your new role.
As a tester, you should develop test cases for these three scenarios, happy path, negative path, and edge case. This is a rule of thumb I use when testing any feature.
Happy Path: This is the straightforward scenario, the path we expect normal users to follow when using our feature.
Negative Path: This involves testing scenarios that are supposed to yield failures — rejections, cancellations, etc. Anything that doesn’t result in success as defined in the happy path.
Edge Case: This can be a bit tricky. Edge cases refer to situations that could happen in your system but are relatively rare. For example, if a customer tries to input the longest village name in the world as an address and your system can’t handle it and crashes — haha 😅!
So, when you’re learning how to test, ask these three questions:
Answer those three questions and you’ll set a solid foundation for effectively testing any feature.
In the last four years, I’ve found that being a QA is quite interesting. You’re expected to master technical skills in coding (for automation) while also possessing excellent communication and analytical skills. This mixed blend of requirements makes the role both challenging and fun, pushing you to grow in multiple areas simultaneously.
So, what do you think? So, ready to take the first step on this journey?