Quality Assurance Engineers are not needed
In this article, I intend to debunk one of the most popular misconceptions in the world of Agile development, namely the assertion that having testers on the team is not mandatory, as developers are perfectly capable of conducting testing on their own. I believe that such an approach may be justified in certain exceptional situations, but in most cases, it will prove to be ineffective.
The IT industry is constantly evolving and transforming every year. However, you can still hear opinions from developers or company managers that testers are not really necessary. After all, developers write code and, of course, check how it works. In addition, they write unit tests that often perform regression testing, which is often done by testers. And to some extent, this opinion is correct. But if you delve deeper into what QA is and what specialists in this field do, a whole new world may open up. Let’s explore this in more detail.
First and foremost, a development team consists of diverse individuals and roles working together to create a product that must meet customer needs. Each team member is responsible for quality, collaborating with others and learning from their mistakes for mutual improvement. And here, you may wonder why there is a need for separate testers when all other team members are already responsible for the quality of their work. And you are partly correct.
How They Live in Agile
Many companies have long been developing products using the Agile methodology, so let’s take a look from that perspective.
Abstractly, it looks like this. Thanks to the information received from analysts, at the beginning of each iteration, developers start writing code, and testers start creating test cases. After developers hand over a completed module to testers, they begin testing according to prepared test scenarios, conducting various types of testing, including regression testing. Sometimes it’s a simple web form, but often it’s much more complex.
A QA engineer contributes a unique perspective to the team, sharing knowledge about testing and the product, closely collaborating with developers to coordinate testing strategies, working with business stakeholders to create acceptance tests, and notifying the start of user testing. QA engineers have been doing significant work in the application development industry for many years. They must understand how microservices, Kafka, Web Socket, REST, SQL, Docker, Git, and much more work.
Yes, a Scrum team is a self-organizing collective that may include one or more testers working closely with developers, designers, Scrum masters, product owners, analysts, and DevOps engineers. Such a team is always ready to respond to any risks and adapt to changes; it is bold and effective.
Of course, Scrum does not segregate people within the team; everyone is equal and performs vital functions for the product’s success. This is crucial because the product’s success depends on many factors, such as development speed and product quality.
Testers are individuals whose job is to scrutinize everything critically. In my view, their work assumes that there are bugs without a doubt. And in reality, this is one of the principles of testing with which I simply agree: successfully passed test cases indicate that there are no bugs where we looked for them, but statistically, they are bound to be where we haven’t looked yet.
QA engineers ask questions and evaluate the product, taking into account customer expectations, testing not only finished features but also documentation at various levels. QA engineers are at the center of everything, like spiders weaving a web over the entire team; they sense fluctuations and adapt with the team. Of course, we’re not talking about beginners; we’re talking about experienced professionals. An excellent tester can significantly influence the results.
It’s true that even in experienced Scrum teams, there are people who find QA engineers annoying with their questions, suggestions, and criticism. But it’s like using both the stick and the carrot; someone has to play this role for the project’s effective growth.
But let’s return to the initial thesis that “developers can test on their own.” Let’s be honest here, developers usually prefer to develop code rather than write thousands of unit tests and, even more so, spend days testing their own features. Let’s also be honest that testers find bugs, often at different testing levels, indicating the need for QA engineers.
And this is just the tip of the iceberg that we see as a result of the work of QA engineers. In reality, QA can be divided into three parts:
- Testing and QC
- QA
Here, it’s essential to understand that QA engineers are not just involved in testing and controlling the current product quality. They must also help the team and the company build effective quality assurance processes, and these processes involve everyone. And it is the QA engineer who is most effective at critically assessing not only a feature but also the team’s and the company’s processes.
But let’s be honest in the opposite direction as well. There are indeed rare cases where QA engineers are not needed. A young startup creating an MVP to test a hypothesis is a suitable example. No one knows if the world needs such a product, and there’s no point in making it perfect.
Conclusion
QA engineers are needed by those who are in it for the long run; it’s a story about product quality and user satisfaction. Look at what successful startups do. They hire experienced QA engineers primarily to establish processes. Testing by experienced QA engineers is undoubtedly important, but predictability and quality assurance processes are equally crucial.
QA engineers may play a less visible role at times, but they are undoubtedly just as important as any other team member, and together, they can achieve remarkable results.
Thank you for reading.
