We have prepared for you a translation of an article by Dmitry Yarygin, QA Engineer with experience in major projects of the world for more than 8 years, a teacher of the Mobile QA Engineer course at OTUS. Is it interesting to develop in this direction? We invite you to take a free two-day intensive "Introduction to the automation of testing mobile applications on Selenium and Appium . "

Quality testing. Who is responsible for this? For many years in my head was the only answer to this question. Of course, a QA engineer! After all, I myself belong to the QA-engineers.

I know for sure how important it is to test the quality of a software product that is planned to be released to the market. However, I noticed some patterns that occur during testing. They made me think about the testing process as a whole and how it could be improved.

Should developers test their code?

Thanks for asking. If you are a developer, then you know all the subtleties and pitfalls in your code, or at least you know more about your code than a QA engineer. You know your code far and wide and understand where the problem may arise.

If you know where the problem area might be, tell the QA engineer. Yes, he himself will find it at some specific moment, but you still know the application architecture better. Testers will be grateful if you tell them where to come from.

We are QA engineers, we will focus on it and cover it with tests so that you are less worried. Any additional information that developers can provide is clearly beneficial.

Unit tests are definitely something that developers should do, this is their area of ​​responsibility. Unit tests will help to avoid unnecessary errors and unnecessary reports about them. Better to avoid the error before the code gets to the tester team, right?

A few words about testing your own code. I believe that developers should at least smoke test their code. No extensive testing is needed. Just check that the code works on some input data set and give it to the tester team so that they already work on it further.

If the code does not work already at this stage, then why give it QA at all? You will get dozens of error messages despite the fact that you already know that there are problems - this will only slow down the development process.

We missed the bug. Are the testers to blame?

Yes and no. Every time an error is detected, especially in production, you and your team have something to discuss. There are several reasons why the error appeared only at this stage:

1. The place where the error appeared was never a priority for testers. Very often, no one thought about the error that appeared on the production. This is the result of a lack of communication between developers and testers. Mutual understanding was not reached in the question of how important this or that area is to check. Classic examples of this negligence are performance and security issues. If you know that these areas are critical for your application, let the team know.
2. QA does not have the necessary knowledge in the tested area. This is also a common problem. The developers wrote the function and automatically assumed that QA understands how it works from and to. Well, making assumptions has never been a good strategy for analyzing the quality of a serious project. If you see some important aspect, make sure that the main QA engineer and his team also see and understand him. There is no way around this step.
3. Developers don't really care. We are all humans. And we all have a life outside of work. Some developers work hard and hard to create a high-quality product, they talk with testers, inform them about possible problems and the like. And there are developers who don't care. They do not use this product every day and do not understand its importance. For them, this is just a side task that needs to be completed and forgotten about it. Simply put, they don’t care that the final product will be of inadequate quality.
4. QA engineers don't care. Here is the flip side of the coin. Not all testers care about the project. Some just need to finish testing, make a beautiful report and forget about it. High-quality test coverage does not bother them, they do not want to communicate with developers. You can discuss bugs, but such testers may simply not find them important or even register.
5. Testers are not qualified enough. Another problem may lie in the fact that testers are simply not qualified enough to test your application. For example, you need to conduct penetration testing, and all that is at your disposal is a team of testers who can conduct only manual testing. In this case, they simply will not know how to approach him. Here you need to either rely on developers, or select more
   
   Qualified QA engineers who will know exactly how to test this particular area.
6. Lack of user research. Developers know how to create an application, and QA engineers how to break it. What about users? Users are real people who will use your application in the real world. They are not going to break it. It's just that they are all different and have different goals, but they all want to achieve them using your application. QA engineers can get used to the error and realize that it occurs infrequently, therefore, it does not matter much. The user will not tolerate this. If your application crashes, the next step is to remove it, and then search for an alternative. That is the reality. Researching a user audience and / or having a test user group are two strategically important things.
7. Poor organization of the communication process. Ideally, you need a simple process for sorting bugs that would allow you to evaluate errors from QA (or at least rank them correctly) and pass them on to developers so that they understand their workload. When there is any misunderstanding, the tester and developer should always be able to approach each other and solve this problem within a few minutes or hours. If this process is not established and both sides are in no hurry to look for the cause of the misunderstanding, then nothing good will come of it. Both sides will imitate activities, but in fact they will both be at a dead end and wait for someone third who can come and magically resolve the situation. This is fundamentally the wrong approach.
8. Not enough testers. An application can be complex and may require testing on multiple platforms and browsers. Just a few QA engineers for this task may not be enough. Consider hiring more people or redistributing the resources you have in such a way as to increase the emphasis on testing.
9. The developers are overloaded. Around you may be ideal and highly qualified specialists, but they work in constant stress and no one can help them. Yes, they are under pressure, and they simply do not have time to talk with the QA team. This is a very common problem and this is one of the main reasons why the software is of poor quality.
10. Quality is not in the spotlight. Consider this scenario as well. Here and there were a couple of minor bugs. None of them are critical. However, users do not like the application. Reviews are bad. UX is below average. And why? Yes, because no one thought about creating a quality product. The developers did their work, the testers did their own, but no one followed the quality control process itself. Application development should combine teams, making them one whole. If such a mood is not visible in the team, then nobody cares about the quality.

Conclusion

Today, applications are getting harder and harder. If you want to find who is to blame for the failure of the project, it's easy. The blame may be QA-engineers, developers and executives. Or all together. The main question is why should we look for those to blame instead of taking responsibility for the quality of the project? Anyone who did not realize the importance of testing a specific function may be in the place of the guilty.

The only question should be: “Are we making a really good product?” If the answer to this question is yes, then there should be no doubt that all teams are doing one big thing.

No one will have to blame and everyone will be happy, because quality assurance is a common task!