In parallel with points we discussed in our previous article, the developer or QA makes a test scenario that takes into account all possible places where problems have arisen. If the developer does this, he will necessarily give the script to QA, which checks it for completeness and sufficiency. If the script is from QA, the developer must confirm that he understands how each of its items can be completed. The team also evaluates the script for correctness.

For compilation and storage of scripts we use HipTest.

Development and Validation

The developer starts writing code based on a technical solution and taking into account all the possible situations described in the test documentation. Passes a code review and checks the code against test scenarios. Also he produces merge in the master.

At this stage, QA provides the necessary support to the developer. For example, it helps with solving complex cases, setting up a test environment, conducting load testing, and tells you about the possible nuances of outputting big features to production.

Release of ready functionality

This is the final stage. Here, the team may be required to pre \ post-release actions, for example, the inclusion of new functionality for beta users.

Documentation and Tools

The new scheme of work required developers more immersion in the testing process. Therefore, as a QA, it was important for me to provide them with all the necessary tools and to teach the basics of functional testing. Together with QA from other teams, we made a list of the necessary documentation, created the missing testing instructions and finalized the existing ones taking into account things that were not obvious to developers.

Then we gave developers access to all testing tools and test environments and began to conduct joint testing. From the beginning, the developers didn’t want to take responsibility for the test results, because nobody else checked anything for them, so it was unusual. Each developer had only a test script, the functionality he developed and the Merge button. But step by step they got used to it.

Experiment Results

Six months have passed since the start of the experiment. The graph displays the statistics of the number of bugs by week in our team. Red color displays the number of all bugs found by the team, green – the number of fixed ones.

It can be seen that the level of the red line remained at the same level, except for the burst at the beginning of the experiment. There are no more bugs, what means we have maintained the current level of quality.

At the same time, the average time for working on tasks decreased by only 2%: before the start of the experiment, it was 12 hours 40 minutes, after – 12 hours 25 minutes. So we were able to maintain the current speed of work on tasks.

As a result, our team now has no strong dependence on QA. If I get sick or go on vacation – the team will continue to work without loss in speed and quality.

Do we consider the experiment successful, despite the fact that the indicators of time and quality remained the same? Yes, we believe, because we have maintained speed and quality of work and freed up QA time for more conscious work on product quality and development processes. For example, to conduct research testing, increase the coverage of functional tests and describe the principles and rules for the development of test documentation in all teams.

In other teams, we also give a push for such an experiment. For example, in one of the commands, QA now does not test what is described by the developer in the pull request, because the developer can see it on his own. In another team, QA analyzes the request changes and checks only complex and non-obvious cases.

Things to remember before starting an experiment

This is a complex and long experiment. It is not implemented easy, you need to carefully prepare for it and not wait for quick results.

Be prepared for the negativity of the team. You can’t just take it and say that now the developers are testing the functionality. It is necessary to prepare them for this, develop approaches, explain the value of the experiment for the team and the product.

The loss of speed at the start is inevitable. Time to train developers, write the missing documentation, and rebuild processes takes time, which will have to be donated to the experiment.

There is no ready-made solution. Similar processes are implemented, for example, in Atlassian, but this does not mean that you will also be able to implement them by your own as is. It is important to adapt to the culture of the company and the specifics of the teams.