Today I’ll tell you about our experiment in transferring to developers part of the testing tasks and transforming the role of the tester into the role of QA (Quality assurance)

First, briefly about our development process. We have daily client releases and from 3 to 5 server releases per week. The development team has 60+ people who are divided into 10 functional scrum-teams.

I work in the Integration team, whose task is to integrate our service into external products and integrate external products into our service. For example, we integrated the Jira task tracker. Jira Cards – a visual display of tasks with which you can conveniently work on the board without going into Jira.

How did the experiment begin?

It all started with a commonplace problem. When one of the testers went to the sick-list, the team’s performance was greatly reduced. The team continued to work on the tasks, but the code reached the testing stage and the task paused. As a result, the new functionality didn’t reach the production on time.

Departure of the tester on vacation is another story. He needs to find in advance one of the testers who is ready to take his tasks in addition to his own, to agree and deal about everything. At the same time, for two testers go on vacation is an impermissible luxury.

We began to think about how to solve the problem, and realized that the real problem was that the weak place of development processes was testing. I will show you an example of several stories.

The first story: endless task rollback

There is me and also a developer. Each has its own tasks. The developer finished one of the tasks and gave it to me for testing. Since this task has a higher priority than my current ones, I switch to it. I find bugs, I get everything in Jira and give it back to the developer for revision.

I return to the tasks that had to be postponed. The developer switches from new tasks to the task that I returned. He corrects bugs and returns me for testing. I find bugs again and return the task again. This process can go on for a very long time.

As a result, the total time of work on the task increases several times, followed by the increase of Time to market, and this is critical for us as a product company. There are several reasons for increasing the time spent on the task:

  • The task is constantly moving between development and testing.
  • The task is “on hold” and waiting for a tester or developer.
  • The developer and tester have to regularly switch between tasks, which requires additional time and energy.

The second story: a growing line of tasks

Our scrum team has several developers. They regularly submit their tasks to me for testing. A queue of tasks forms, based on priorities.

So like this we worked for about a year, but during this time the company has grown significantly: the number of projects and developers has increased, which means the number of tasks in testing. At the same time, I was still the only tester in our team and could not multiply my speed. As a result, more and more tasks were accumulating in the testing queue, and the process of transferring tasks between the developer and the tester increased the waiting time.

Suddenly I got sick. Delivery of new features from our production team has completely stopped. What should a team do in such a situation? You can ask the tester for help from another team. But, with a high degree of probability, he will not be immersed in our specifics, which will negatively affect the quality and timing of both teams.

The conclusion from both stories is the same – the teams depend too much on the tester:

  • The performance of the entire team is limited by the performance of the tester.
  • The number of developers cannot be increased without increasing the staff of testers.
  • An increase in the development speed doesn’t make sense if all tasks fall into the queue for testing.
  • While the work of the developer is checked by the tester, the developer’s sense of responsibility for quality is reduced.
  • If there is no tester, then the process of publishing new functionality is damaged.

Let’s increase the staff of testers?

The most obvious thought is to increase the staff of testers. This will work, but only until a certain point: the number of tasks will constantly grow, and it is impossible to infinitely increase the number of testers – at some point it will become expensive and inefficient.

It is much more efficient to maintain the speed and quality of development within current resources. Therefore, we decided to launch an experiment that will help teams create functionality immediately, taking into account all risks and border situations. They called it Transform tester to QA, because it is about the transformation of one of the roles in the team: from a monkey tester, identifying errors by the developer, to a QA engineer, who consciously ensures quality at all stages of the development process.

Let’s improve the development processes

Objectives of the experiment:

  • To remove the team’s dependence on testers, but without loss of quality and time.
  • Improve quality assurance by QA engineers in teams.

The first step was to change the thinking of the team. Everyone is used to the fact that the tester is responsible for the quality of the team.

Our hypothesis was that increasing the time to prepare and test tasks would help to reduce the number of iterations in working on one task. This, in turn, will allow bringing new functionality to production without loss of speed and quality level, and maybe faster and with better quality.

Together with the team and with testers from other teams, we developed a new working scheme. For half a year, as the team works on it, we took into account the difficulties and problems that arose along the way, and today it looks like this:

  1. Presentation of the production.
  2. Technical solution and test scenario.
  3. Development and verification.
  4. Release

Formulation of the problem

Product Owner presents the task to the team. The team analyzes the formulation in order to identify borderline situations from the technical and product sides. If there are questions that need to be further investigated – a separate task is set, for which time is allocated in the sprint.

Technical solution

The result of the analysis of the problem statement is a technical solution that consists of one or more developers. All relevant company employees, including QA, must be familiar with and agree with the technical solution. The technical solution describes the problem that we are solving, the functional blocks of the product that will be affected, and the proposed plan for making changes to the code.

This solution allows you to identify a simpler, better solution based on the experience of relevant participants in the development process. Having a detailed technical description on hand – it is easier to see and avoid blocking problems, it is easier to conduct a code review.

Here is an example of some blocks from a technical solution:

Task description

Are new entities or approaches added to the system?

If yes, they are described and explained why it is impossible to solve the problem within the framework of existing approaches.

Is server interaction changing within a cluster? Are new cluster roles being added?

Is the data model changing?

For the server we are talking about objects and models.

If the data model is complex, you can represent it in the form of a UML diagram, or as a text description.

Is the interaction between the client and server changing?

Description of changes. If this is an API, can it be given to external users? Do not forget about error handling – i.e. indicate the correct reason.