Testing is not (only) search bugs
Head of QA Redmadrobot Marina Kulikova argues about testers and “monkeys”
For some reason, it is considered that testing is the easiest entry point into the IT world. Over the years working in different companies, countries and roles - from the tester to the Head of QA Redmadrobot - I managed to try different approaches and step on a different rake. In this article I will try to answer the most popular questions and help beginners to QA-engineers to find out what awaits them.
Open and poke
To begin with, let's deal with the main misconception: to test means to open, poke all the buttons and forms and spam bugs. I encountered this conviction both among testers and at the level of company executives.
As a result, questions and resentment arise: why does this testing creep into the product, code, and design? Their task is to check all possible combinations of buttons! Of course, this too. But applications, for example, MonkeyRunner for Android, also cope with buttons poking.
And who will test the wired logic, backend, edge scripts and the rest? In theory, the tester’s responsibilities include: - preparation of test design, test cases, testing strategies, - report and check bugs, - verification and creation of test documentation (artifacts) - security check - recommendations on the release of the assembly (product) - yes, yes, in all utopian postulates it is stated that only QA / QC can give the nod to the release of a product
And if the development of test design and test cases is not so simple, in most companies at least they guess by drawing to this and writing cases for test design QA Team Lead or Senior QA or even creating a separate role for it TC Designer (writer). Various strategies for checking edge values, interface testing, load testing, etc. Test cases are written by senior engineers, and the test itself is performed by ordinary testers - people who at best have computer user skills and some kind of product. Although some scripts and running SQL scripts, working with third-party tools are not available to every experienced user. And companies consider it normal to contain 20-30 such monkey specialists, calling them testers.
As you can guess (actually possible!), This is wrong. Both in terms of business and in relation to specialists. QA / QC engineers can bring much more value if they are trusted and invested in their development. At a minimum, the whole team won’t have to spend time on the initially unviable design and business concepts - a good QA / QC can reveal such cases at the design stage.
In order to be not a monkey pushing buttons, but a really useful specialist, a tester should be able to read the code at least at an intuitive level, understand the logic of developers and think not only with algorithms, but also with processes. Ideally, also quickly adapt to new languages and programs / environments.
Yes, in an ideal world, the process should run according to the black box model, but if the service is slow, though true - maybe it is worth optimizing the code? Or, for example, you need to design a negative scenario - to prepare such a test, you may need to add something in the code or change necessary data to the program. And yes, this is the task of QA / QC specialists - do you want to have a quality product after passing the test?
The tester should not be afraid to look into the code and help the developer to deal with the problems. Code review, debugging and unit testing is not the prerogative of developers. We do not question their competence, just quality assurance is the responsibility of the whole team. Testers should also remind and bear the burden of quality control (the process is a manager)! QA —Quality Assurance; QC — quality control. This is useful to remind those who do not feel the difference.
Is it possible to build something grand and cool to manage this product, without knowledge about how each screw and gadget works?
To know the code doesn’t mean to automate everything without restraint.
For some reason, it is believed that testers are divided into automation testers and manual testers (manual). And most of the manual dreams of becoming automation.
To begin with, let's make a clause - in order to go into automation, you need to master the basics of testing, designing and designing cases. Real specialists are able to work this way, and by the way, they understand that not all projects and teams need automation.
The feasibility of automation is highly dependent on the specifics of the project: timing, support, repeatability, stability, and other parameters.
Let's calculate how much will be spent on the organization of the infrastructure for automatic tests, the search for automation engineers, development and - most importantly - the support of automatic tests? In most cases, it is easier to do unit-tests - they are often very well done by developers and complete functional testing (this includes the sea of everything).
If you want to check that everything will “take off”, you can add beta testing to the mandatory set. And, of course, you need to competently conduct acceptance testing (acceptance).
If testing as a separate stage is required, it is much easier and more efficient to have the delivered process of the product and person’s life cycle or a team of engineers able to independently cover the tasks of testing, controlling and ensuring the quality of the product. That is, people who beforehand know the area, tools and methods, and not a herd of monkeys, which are hung on the developers or project manager.
Probably the biggest problem is that the idea of testing is very vague. In many companies, the approach to testing monkeys, and in IT, where there is a general idea of the processes, there are problems with fixation on individual roles or tools. Although this approach is poorly applicable to testing.
The objectives of the tester in relation to the product are closest to the goals of the business and the strategic goal of the company. At the same time within the company is the role of the researcher.
Most often testing is tasked with improving quality and reducing the number of bugs and rejects. Coordination of departments, drawing up plans and organizing testing and quality control, working with developers, drawing up a database/storage of cases, etc., hides behind its solution. To do this, you need authority, which most of the time, nobody is ready to give the testing department, and a team that does not exist and is not planned in the future. But it is testers engineers who can become the experts who organize the processes of control and quality assurance and will become a link at all stages of the project. Just give them that opportunity and that authority!
Initially, the problem is in the formulation of tasks for the testing department and its development. Creating a testing department and debugging at least the quality control process should be considered as a new project within the company. And, as with any project, set the correct requirements. The reason for the inefficient work of the department may be the incorrect setting of goals and objectives in the almost complete absence of authority.
It is important to remember that a good QA department is not 20 monkeys, but 2-3 normal specialists. They know how to build processes, how to avoid bugs in scenarios and design, what to change to make the product qualified. But for this, first of all, it is necessary to change the attitude to the testing department and understanding of who the testers are.
Ideally, quality management (QA) and testing are two different entities. Well, about the processes and the difference between QA and QC in a different text!