In the new issue of the “Sushite Vesla” (“Dry your Oars”) podcast, Android developers invited the QA guys to visit. They discussed what kind of discipline this is, how it is useful for business and how to test a rocket without asking Ilon Mask. And thanks to vc.ru and NIX Solutions, you can read a summary of their talk.
What is QA?
QA, or Quality Assurance, is the discipline that is responsible for product quality. For example, for the quality of a mobile application. Usually it is integrated into all stages of a project. QA specialists prepare and implement development standards, check quality, prevent errors, and constantly improve internal processes. QA is used not only in mobile development, but also on the web, in industry and in many other areas.
What is the difference from a tester?
Globally, QC (Quality Control), or testers, are part of QA.
The tester studies the product, conducts research, works out possible scenarios and catches bugs. They provide the team with an overall picture of the product. QC does not improve quality, but gives an idea of what is happening in development.
QA also helps the team to establish processes related to quality. They look at the whole picture and make it so that there are fewer errors.
QC is about the result: finding bugs. QA is about the process: debugging development processes so that there are no bugs.
Should the tester know the programming language in which the program is written?
The tester does not need to know the language and technology, but this can be a plus in the job.
The code is written: the developer writes the code, and the tester is looking for bugs. How to avoid quarrels?
The developer is thinking how to do well. The tester thinks how to test to find why this is bad. There is a certain conflict of interest.
We have a hypothesis that it all depends on how far QA is from the developer. When they are sitting nearby, they reflect on the task together. This works better because the level of trust is higher. Being in different departments or companies, it is difficult to achieve such mutual understanding. It remains only to be angry at reports from unfamiliar guys.
This also happens with specialists at the beginning of the journey. Young QA and developers have little experience in teamwork, so some difficulties can arise. Over time, there is a realization that you are partners, working on one product and doing it better together.
Only failed programmers go to QA?
It happens in different ways, some start testing because they love it. For example, Sasha, our Head of QA, left programming because he likes to break everything more.
Is it possible to “migrate” from one type of testing to another?
In short, yes. A tester is a tester everywhere: they must be able to create bugs, understand how tests are written and so on. If you wish, you can figure out a new direction in a few weeks.
But how to test a rocket?
We are testing software and are not related to space. But we can assume how this could be.
As in other tests, here we are dealing with a list of characteristics of the object. Its materials, wear resistance, heating or cooling temperature, the amount of fuel per flight and hundreds more points.
If the tester wanted to test the rocket, then they would do anything with it: they would heat, cool, send it to a distance that it was not designed for, and so on. The development of such scenarios, proceeding from the documentation for the object or from empirical knowledge, is able to identify defects, the correction of which determines the quality of any product.