The authors of the November “ Tester Calendar” were Olya Fazulzyanova, Kontur.Externa tester, and Olya Izyurieva, Kontur.Billinga tester and organizer of the testers course. The girls talked about paired testing, the tasks it helps to solve, and gave an example of the unsuccessful use of the practice.

There is a practice in XP methodology - pair programming. Many sources have written about the mass of its advantages: high quality code, interchangeability of developers, etc.

If pair programming is so efficient, why not apply similar principles in testing? Yes, it can be done, pair testing has existed for a long time and has proven itself well. But do not forget that any practice is just a tool for solving any problems.

Wikipedia does not have the term “pair testing”, but there is a definition for pair programming that can be taken as a basis. Then, in our opinion, we get the following.

Pair testing is a technique in which testing of one functionality is performed by a couple of people at the same workplace. One tester ("master") controls the computer, the second ("navigator") continuously monitors the work of the first. At the same time throughout the work on the task, they exchange ideas and discuss them.

Any practice is just a tool. We do not want to hammer nails with a microscope, so we always make a start from the task. Let's look at those tasks for which the use of the “pair testing” practice is relevant.

Task: Mentoring

At any time a new person can join the team. The expectations of the team from him are fairly quick immersion in the team and in the specifics of the project and, of course, high-quality performance of their work. So that expectations are rapidly becoming a reality, in many companies there is a process of mentoring. But what will happen if the mentoring is implemented through pair testing?

Example:

A new tester came to the project, with experience or not - it doesn't matter. You, as a mentor, sit down with him at your work computer and begin to build the process as follows: at the very beginning, you are assigned the leading role, and the primary goal is to acquaint the newcomer with the project processes and subject area. Acquaintance can be through a story, presentation, or immediately through joint testing of tasks.

You can start by discussing the essence of the problem, finding answers to questions and working out a test plan. When everything is ready for testing, you take the keyboard and mouse and show how to test, and the novice is watching. Nobody forbids changing roles and jobs on subsequent tasks. The main thing is not to change the essence - joint testing of tasks behind one workplace until you are sure of your partner.

Profit:

• The newcomer adapts quickly to the team. He has an entry point - a mentor through whom you can get to know the rest of the team. Also, the novice will form an idea about the area of ​​responsibility of colleagues, because in the course of searching for answers to questions you will immediately send him to the right people.
• The newcomer will quickly deal with a new subject area.
• If a novice has no testing experience, he will learn in practice about new testing techniques and evaluate their applicability.
• There is a sharing of knowledge: about development processes, about techniques, about testing tools.
• The newbie’s eyes are not blurred, so he can bring in new non-standard scenarios.
• Mentor quickly determine the level of preparedness of a new person. This will help to correct the development vector in a timely manner, selecting tasks for it.
• Timlid testing and / or development manager are not distracted by the beginner adaptation. The newcomer is in safe hands, and there will definitely be no problems with the quality of the first tasks.

Mini-output:

Practice is suitable if the partner is a person without experience and you need to quickly convert it from a beginner to a specialist. Profit is also when working with an experienced novice: everyone learns, including the mentor. After all, each person works in his own way and thinks in a unique way, using his own practices and tools.

Task: professional development

We may be faced with the fact that in order to successfully complete our work we need to have knowledge of related specializations: be able to compile documentation, automate tasks, etc. How to quickly and inexpensively increase competences? Refer to a member of your team.

Example:

As a tester, you receive a task that is more appropriate to cover with unit tests, but you do not have enough qualifications, and you go to the developer for help. You sit down with him for one working computer and begin to build the process as follows: at the very beginning, the developer must take the lead, as he has to introduce you to the code base and the available tests. Then you put the scripts together and start automating them. The first tests are written by the developer, and you observe, and the following you already take in your hands.

Profit:

• You will quickly figure out how the project is arranged and what tests are already there.
• Learn not only to write tests, but to write them correctly (stylistics).
• The developer will expand their ideas about testing scenarios, because you will show how to think outside the box.
• The developer will expand his understanding of the testing process, because you teach him to check the quality of his code before passing to testing.
• The task will be covered by autotests for a shorter period.
• A manager or team leader will appreciate your desire to develop.

Mini-output:

Working in pairs allows you to gain knowledge in the new field quickly and efficiently, immediately consolidating them in practice.

Task: getting rid of indispensability ( bus-factor )

Very often there are people in the teams - the only carriers of certain knowledge. Often this person becomes a tester, because he knows everything: user scenarios, how services are implemented, what needs to be set up for the test, and much more. But in life there are situations that can deprive a project of a source of knowledge (dismissal, vacation, sick leave ...). Consequently, in order to minimize the consequences, it is possible to insure and share knowledge from one head to several in advance. How? Through pair testing, of course!

Example:

As a tester, you need to immerse any team member into your tasks, passing on sacred knowledge. You sit down with him for one working computer and start to build the process as follows: you are always assigned a leading role, at the very beginning you tell and / or show sources of information, updating, selecting and analyzing tasks that will help consolidate the knowledge gained.

Profit:

• The pressure of responsibility diminishes, you can safely go on vacation, on internships, etc.
• Working in pairs will allow you to change the context and dilute the routine of a highly specialized tester.
• The manager is calm, because several people have the knowledge and with the departure of one, the work will not arise.

Mini-output:

If there are narrow specialists, then the pair practice for you. It enhances the interchangeability and transfer of relevant information.

Task: getting feedback

If the testing team consists of several people, the feedback practice is applicable. Pair testing is a suitable tool for the OS.

Example:

You or your colleague needs feedback. You sit down with him for one working computer. How to build a process is not important, the main thing is to work together.

Profit:

• You or your colleague will have an idea about partner’s skills.
• You or your colleague will have an idea of ​​a development vector based on feedback.
• Feedback about colleagues will be reasonable, because it will be supported by examples.

Mini-output:

Paired sessions give testers the opportunity to observe the work of colleagues, with the result that the feedback will be more reliable.

We have analyzed tasks that can be solved by pair testing.
And now we will tell about the real experience to illustrate the pitfalls that can occur when using this practice.

The case of life, or do not do as we

At one of the retrospectives of the testers team, the following problems were identified:

• unequal work (the method and time of testing similar tasks strongly depended on a particular person);
• too vague feedback about each other (often only one person was engaged in one task, and at the end of the first half of the year many colleagues have nothing to write about, except for “Vasya does his job well, he is responsible, responsive and sociable”).

Having formulated these problems, we set ourselves the following tasks:

1. Exchange experience and identify the best methods and tools for testing similar tasks.
2. Create conditions for collecting more detailed feedback.

We agreed that we will use the practice of pair testing to solve them.

My colleague and I both started the same testing task.
The front of works was quite voluminous, it was required:

1. Understand the new domain.
2. Check analytics and find unaccounted scenarios in it.
3. Prepare the environment for testing.
4. Prepare test data.
5. Create test cases.
6. And test in the end :).

All this had to be done from scratch.

Having sat down at one computer, we began to read analytics. We agreed to read one paragraph or a part of the text, and then discuss the questions that have arisen and cover up the first test cases. Since the analytics was rather poorly developed and contained a mixed business and technical part, sometimes it took 15–20 minutes to discuss 10 lines of text. In addition, in order to finally deal with each question, it required clarifications from the analyst, developer or technical support specialist. All these messages and letters were also written in pairs.

The new subject area was quite complex, so drawing up test cases required setting up a complex environment and preparing some of the test data. Here, too, was not without many questions and joint clarifications.

Faced with all this, we decided to slow down and hold a meeting to discuss the progress of work and the success of pair testing.

At the meeting, we realized that when we started applying the practice, we completely forgot about the purpose of its use. All attention was focused only on testing, more precisely, on preparing for it, since the case itself didn’t come up to run the test cases.

In the course of work, we did not manage to conduct a full-fledged review of each other, because we carried out all the actions together before discussing them. We did not notice the course of thought and actions of the partner in the process of unwinding a new task. It was not possible to exchange knowledge either, since the subject area was new for both of us.

Strictly speaking, to share knowledge turned out, but it was little things like:

• use new hot keys,
• using some specific bugtracker tweaks,
• ...

This knowledge can be shared without resorting to such an expensive practice.

By the end of the meeting we made conclusions for ourselves:

1. Applying the practice, we should not forget about the initial tasks.
   It seems to be at the start everything was done correctly. We formulated the problem, set the tasks, chose the solution tool, but during the work itself the emphasis shifted. In our case, we only achieved that two testers were engaged in the same task.

   
   

2. Select testing tasks so that the practice is applicable.
   A new, complex and voluminous task is poorly suited for pair testing:
   - it is difficult to train someone;
   - I can't exchange experience;
   - it is difficult to collect feedback.

   
   

3. Do not gloss over problems.
   As soon as you feel that something has gone wrong, immediately talk about it, do not wait for the end of the task or the final retrospective of the team’s work. So you can quickly understand that the practice is applied incorrectly, or it may turn out that it is not at all suitable for solving your chosen problem.

   
   

There are many different practices. Which of them to use in work depends only on you. Most importantly, do not forget why you apply them, and do not use the practice for the sake of the practitioner.

PS If you used pair testing for other tasks in your working life, tell us about them in the comments.

List of calendar entries:
Try a different approach
Reasonable pair tested
Feedback: as it happens
Optimize tests
Read the book
Testing analysts
tester should catch a bug, read and organize Kaner dvizhuhu
load the service
metrics at the service of QA
test the safety of
Know Your Customer
Disassemble Backlog