Starting Your QA Journey: 10 Lessons Every New Software Tester Should Know
At the beginning of this year, our company welcomed a new junior QA engineer fresh from college. Stepping into her first job, she was understandably finding the experience a bit overwhelming. Every day, she was gaining new knowledge, and each tester introduced her to a different field, project, or approach. One day, she came over with a question that caught me off guard: ‘When will I start looking at the developers’ unit tests?’ I was momentarily surprised and explained, ‘Actually, you won’t be doing that — it’s another developer’s job to check those.’ She looked a bit embarrassed but then expressed her relief. She had been under the impression that reviewing unit tests would be a major part of her role as a tester, a task she wasn’t particularly looking forward to.
This took me back to my debut in the world of software testing, filled with expectations and surprises alike. While some aspects of the job aligned with what I anticipated, there was so much more to learn on the job. Now, with several years under my belt, I’m in a position to reflect and offer insights on what newcomers should know as they start a career in software testing and quality assurance.
More About People Skills than Tech Knowledge
When I started in the testing field, my first role was as a Verification Engineer. Fresh out of college and seeing the word ‘engineer’ in my title, I braced myself for in-depth technical discussions and a significant amount of code cleanup. I thought, being an engineer, I’d spend most of my time in solitary work, just me and my computer, right?
Contrary to what I initially thought, the role involves much more than quiet hours at a desk. A significant part of the job is communication, and I’m not just referring to meetings. You’ll find yourself frequently reaching out to colleagues to ask specific questions, clarify software specifications, and discuss the current state of the software. It’s a role that requires as much interaction with people as it does with technology.
Effective communication is a cornerstone for a software tester, so it’s essential to be prepared for it. While your role may sometimes involve more writing than verbal conversations, interaction with others is inevitable. Being a QA engineer demands considerable communication skills. If engaging with people isn’t something you enjoy, then a career in this field might not align with your preferences. It’s important to recognize that this role is as much about collaboration and clarity in communication as it is about technical wisdom.
Dealing with Constant Questions About Your Job
When I began my journey at my first company, I was brimming with motivation, and eager to excel in my work. I had this notion that my findings and suggestions for improving our current system would be warmly welcomed. Believing that my role as a guardian of quality would not only earn me respect but also make me an indispensable part of the team, I was optimistic about the impact I could make.
But there were numerous interactions with other people who not only questioned the essence of my job but also inquired about our specific activities. Not everyone initially understands the significance of the tester’s role. Over time, the understanding and appreciation of testers have grown, yet there are still those who don’t fully grasp why QAs are essential and why every software company needs them. This ongoing need for awareness and education about our role is a part of the journey in quality assurance.
I frequently encountered questions like, “Why can’t the product owner or the developer test the feature themselves?” Once, a former colleague even asked about the difference between a product owner and a QA engineer. So, be prepared: you might find yourself explaining and even justifying your role to some people.
Embracing the Never-Ending Journey of Your Work
One of the fundamental principles in testing is, “You cannot test everything.” It’s practically impossible to examine every tiny detail of software and account for every possible state it might be in. Testing, in a sense, is a Neverending Story (initiate the ’80s music reference). In my early days, I was driven to test exhaustively and uncover every bug, only to realize that time and budget constraints make this goal unattainable. This taught me to accept that my work might never feel ‘finished.’ Even post-release, I often find myself thinking of additional tests or spotting bugs. While it’s important to report these, I’ve noticed that more often than not, the fixing of these bugs may be ignored until users raise complaints. It’s a reality of the job that emphasizes the balance between thorough testing and practical constraints.
Mistakes Will Be Noticed, But Quality Work Could Be Overlooked
As I mentioned earlier, you might thoroughly test the most critical feature and feel confident that the end product is of high quality. Upon its release, everyone is content, and perhaps the developers will be praised for their work. In such scenarios, it might seem like your contribution as a QA is overlooked because everything is functioning smoothly. This can be somewhat disheartening.
Conversely, if a bug surfaces in production, the immediate reaction often involves questioning why it wasn’t caught during testing. It can be challenging; you might have identified 99 out of 100 bugs, but that one oversight can lead to scrutiny of your work. Being prepared for this is crucial in the QA field. Moreover, encountering an overlooked bug isn’t the end of the world. Every software has its share of bugs and errors — and trust me, there are many. When this happens, it’s important to own up to the mistake, learn from it, and move forward.
However, the true reward comes when users and stakeholders commend the product’s quality. That moment of recognition, knowing your diligence played a key role in achieving such high standards, is incredibly gratifying for a QA engineer. It’s a unique satisfaction that comes from knowing you’ve made a significant, though sometimes unseen, impact on the product’s success.
Prioritizing Quality Over Routine Testing
It’s common to hear people say they’re software testers, focusing on how the software is supposed to function. However, when asked how they measure quality, many struggle to articulate an answer, even though their actions are already a part of that measurement process. Testing is fundamentally about gathering information about the current state of a system. A passionate and skilled tester will collect as much data as possible about it. Gathering detailed information helps you to make well-informed decisions about the product’s quality.
In many cases, a tester is the person with the deepest understanding of the software’s quality. This knowledge places a significant responsibility on your shoulders: the quality of the product. This responsibility should be evident in your work approach. Remember, testing is not the entirety of your role; it’s a part of a larger process of quality assurance. Your job involves not just identifying issues but understanding the broader picture of how the software performs, behaves, and satisfies its intended purpose.
Writing Code Is Not Essential, But Highly Beneficial
I firmly believe that every tester or QA engineer should learn coding, particularly for test automation. While it’s not strictly necessary, it has multiple benefits: it expands your skillset and mindset, and it deepens your understanding of what you’re testing.
Coding your own projects can enhance your comprehension of developers’ intentions and help you quickly grasp the meanings of various errors. It also shows you the weaknesses in the code, leading to more creative and better ways of testing. On a personal note, I find the process of writing code or test automation quite fulfilling. It offers a distinct perspective compared to manual testing, providing a refreshing change of pace and an opportunity to apply a different skill set within the QA domain.
Stress Reduction Through Improved Communication
I’ve already emphasized how crucial communication is in your day-to-day work as a QA professional. Given its significance, my advice for those starting their careers in this field is simple yet vital: improve your communication skills.
Effective communication isn’t just about talking; it’s about understanding and using the right terminology, choosing appropriate words, and addressing issues in a manner that resonates. This skill takes time to develop, and I’m still learning new aspects of it through regular interactions with colleagues. Communication can often be complex, given that each individual has their unique style and preference for receiving information.
To the newcomers, my lesson is this: Get to know your team members. Understand their communication styles and preferences. This understanding will not only make your interactions more effective but will also help you become a more proficient and respected member of the QA team. Remember, good communication is as much about listening and adapting to others as it is about conveying your thoughts and findings.
Finding Courage to Express Your Opinion
Embarking on a career as a tester places you in a unique position within the software development cycle. Your role centers around identifying errors and bugs, which inherently involves critiquing others’ work. For someone new to the field, especially a junior QA, this can be daunting, particularly when you need to report bugs in the work of more experienced, senior developers. Yet, it’s crucial to be brave and speak up — it’s not just beneficial; it’s essential!
In the early stages of my career, I sometimes held back from pointing out potential issues because I was unsure if they were genuine bugs, or I didn’t want to inconvenience the developers. However, almost every time I chose to stay silent, those bugs were eventually discovered by others, and I found myself accountable for not voicing my concerns earlier. This experience taught me the importance of overcoming the fear of speaking up. Remember, as a tester, your primary responsibility is to ensure the quality and functionality of the software. Your observations and insights are valuable and necessary for the development process, regardless of your level of experience.
Every Project Calls for Distinct Testing Approaches
When I started my career in a project-based environment, I mistakenly thought that after learning a few projects, my job would get repetitive and I’d simply be doing the same tasks on autopilot. I thought that each project, especially within the same sector, would be quite similar.
However, after being involved in numerous projects, I’ve realized that no two projects are the same. Even if you’re working on two e-commerce projects or two applications in the health sector, each one is unique. Some elements might repeat, like input fields and certain features, but the overall experience of each project is distinct. This could be due to working with different people who have varied levels of expertise and backgrounds.
While this diversity can be intimidating for some, I really like it. Every new project brings fresh challenges and lessons. This variety keeps the work engaging and constantly evolving. Adopting the right mindset is key. As a tester, if you embrace the multiplicity of projects, you’ll find each one offers a new opportunity to learn and grow. This perspective turns what could be a daunting aspect of the job into one of its most rewarding facets.
Mastering the Art of Creating Impactful Documentation
I’ve emphasized the importance of communication extensively, but there’s another aspect of it that’s vital for a tester: documentation. Early in my career, I recognized that documentation was crucial, particularly in the MedTech field. However, I also observed a tendency in other areas to downplay its importance, with some even suggesting that generating detailed test reports wasn’t a priority.
Let me assure you, that the ability to produce effective documentation is a critical skill and constitutes a significant part of your role as a tester. Firstly, it’s essential for communicating issues like bugs to developers. But perhaps more importantly, it serves as tangible proof of your work — what you’ve tested and validated. As I mentioned before, when issues arise in the software, you’re often the first person to be questioned about whether the problem was tested. In such situations, being able to demonstrate that you did indeed test it and that it functioned correctly at that time, can be immensely valuable.
Effective documentation is more than just a record; it’s a testament to the thoroughness and quality of your work. There will be moments when you’ll thank your past self for the precise documentation of your tests and findings. As a tester, be prepared to invest time and effort in learning how to accurately document your tests and results. It’s an investment that pays off significantly in establishing your credibility and the integrity of your work.
Conclusion
If the points I’ve discussed so far don’t resonate with you, it might be a sign that a career in software testing isn’t the ideal fit. Of course, there are many other facets of this role that I haven’t covered in this blog, and everyone’s experience in QA can be quite different. I’d love to hear about your journeys and lessons learned in the field of quality assurance in the comments.
From my perspective, I genuinely enjoy my job every day. The opportunity to work with people and contribute to creating digital experiences is deeply fulfilling for me. The job of a QA engineer comes with important duties, which could be overwhelming for some people, but I enjoy the feeling of being responsible. The knowledge that I play a crucial role in determining the timing and readiness of a software release is both empowering and rewarding. This sense of responsibility towards ensuring quality is a key aspect of what makes this job so engaging and important.
If you’re interested in more content about Software QA, Artificial Intelligence, Digital Health, and Self-Development in general, be sure to follow.
Twitter: @theRealTestify
Instagram: @therealtestify
