In some companies, the entire responsibility for the code lies on developers. It is believed that developers write the code, and they have to test it. Why then are QA engineers needed? And whether they are needed at all?
We at Mad Devs aren't asking such questions. We adhere to the rule “people who wrote the code shall not test it”. We have QA engineers in our team, and we appreciate their job. While our developers cover everything in tests, they cannot find all the issues. The reason is simple: developers and QA engineers have different mindsets. They approach a product in different ways. Developers perceive the code as their creation, as a piece of art. It might prevent them from seeing faults.
Let me give an example.
Imagine that you have created something. It can be just anything, but in our case, we can take a blockchain app. If you have to test it, you check how it works, whether all the processes are performed smoothly, and similar. You aren't thinking of making it break down. Moreover, you don't want it to break down.
While a quality assurance engineer does so. It is their job, and they were trained for it. The task of a QA engineer is to find or create conditions that may force your app to break down or work not as expected. They will try to find those combinations of conditions that will make the feature collapse. Moreover, QA engineers have all the needed tools to do so (here, I mean automated, not manual testing. While manual testing is required, we cannot deny that without automation, this work cannot be done at a proper level).
People still mistake QA engineers as software testers. There is a difference between them. QA engineers are engaged in the work on a product constantly. While software testers test the final result or test the product after a specific stage is completed.
It looks like now, it is clear why QA engineers are needed and what they are doing. However, another logical question arises: how is it possible to avoid confrontation between developers and QA? If the approach to the QA processes is not correct, specialists might end up in a conflict. So, QA engineers might start accusing developers of writing low-quality code, while developers might feel as if QA experts are too biased in their search for bugs.
We at Mad Devs eliminate the possibility of such situations by adhering to the following principles:
We focus on quality. We never do tests for the sake of tests. Users don't care about the number of tests you have run; they care about the product quality and convenience. That's why we never run tests for the sake of running tests.
We choose the battles correctly. We prioritize tasks to concentrate on those issues that will influence the user experience rather than those that don't have any visible impact on users or the product functioning. If a feature is not essential and doesn`t influence the user experience, it might not be tested profoundly (upon the agreement with the client, of course).
We respect each other. So, a QA engineer will not blame a developer for low-quality code, and a developer understands that if the app didn't pass tests, it should be improved.
Finally, we always share responsibility for the final product. In our team, there are no “us” and “them”, developers and QA engineers. Everybody works in a team to deliver a quality product. Therefore, the team is responsible for the final result, not a separate specialist or department.
Previously published at maddevs.io/blog