Unit testing in modern teams

Who is this article for?

This article will tell you how we managed to implement the unit testing process in teams working according to the classic cascade model, as well as in teams with a flexible methodology (agile). In our organization, in any team, project managers are responsible for the overall process and filling the sprint with tasks, who also participate in the discussion of the types of testing required for each task (joint brainstorming) and make the final decision. Therefore, my article will be primarily aimed at project managers in teams (just because we have such a role) and all those who are engaged in similar tasks.

For which teams is this suitable?

I would like to show you the process of implementing unit testing for 2 types of teams. In teams that work according to a flexible methodology and in teams that have chosen for themselves a cascade style of work.

The diagram below shows the schematic structure of teams by roles:


From this scheme, we can conclude that the project manager, receiving tasks from the product holder, coordinates them with all participants in the process and includes (or not) them in the sprint by results.
')

How is unit testing different from the usual?

Now I would like to tell you what unit testing is and how it is implemented in our case:

To begin with, unit testing experts are experts in their fields (this is most often understood as a specific system). They possess the broadest backing ground and the necessary technical skills. Each system requires its own knowledge, somewhere it is Pl / SQL expert knowledge, somewhere specific development languages, and somewhere only long-term experience with a particular system. We do not affect the front-end system. We stand guard over the systems of middle and back levels.

Probably it is not a secret to anyone that the development / refinement of any feature includes changes in systems at various levels. Each module tester checks new functionality only within its system. The code is tested, the compliance of contracts without the use of an interface The sampling of test data also occurs not blindly, but on the basis of the principle of a minimum set of data covering the maximum number of variations in output parameters. For us, the main functional and technical correctness of the written code.

The first difference in unit testing from other types is that we look into the code and focus on the immutability of the recorded contacts / output parameters. If they are fixed and not violated, then in the process of integrating systems, the feature is enabled without problems.

And the second is a significant reduction in the time for testing the revision due to the expertise. Integration testing looks at a feature entirely, but we consider it in parts. What problems does unit testing solve? Based on the foregoing, it is possible to draw a line and answer the question: what problems does unit testing solve?

1. Testing of the functional in the context of "its" system.
2. Technical testing of the code for not only processing correct data, but also generating errors and exceptions.
3. Transfer of functionality to integration testing without critical bugs and blocking defects.

These are perhaps 3 main points that I would like to highlight. You can talk for a long time about the fact that errors found during the development process or immediately after it are corrected faster and less painful, but you know that without me. Just as you know what specifically described a bug at the code level, the developer perceives a lot easier than a common bug in the process.

The benefits of implementing unit testing

After reading all this, the question will arise, and what advantages can one get from the introduction of unit testing? Earlier, I gave 2 schemes of work of teams, and now I will describe with reference to each of them:

Team working on agile methodology. The diagram below shows the place for unit testing in a team of this type:


In this case, unit testing is connected at a later stage of development, when code licking is actually taking place, and all the main functionality has been developed. It is not necessary for the modular tester to start the process from the beginning, in order to see whether the development on the back office system or the integration bus has been carried out correctly.

In the agile team, all participants in the process, prior to the start of development, know what features they have taken in the sprint and understand how they should work from the end user's point of view. As a result, we come to the fact that the time that needs to be spent before a specialist starts testing is close to zero. We do not need to write test cases (do not be in a hurry to wonder how it is, but what about the transfer of knowledge and the like), we immediately climb into the code and proceed.

After the development is completed, we get that the task goes further to the tested and not containing critical bugs (both from the development side and from the analysis side). And what about the non-critical? Such bugs are found, but extremely rare and usually they are tied to very specific test data. Each such case is processed and entered into teams wikis. But that's not all the buns that are obtained at the exit!

If there is an automator in the unit test team (we have one!), We also get automated unit tests at the output! This can be a set of tests on any selected test framework, or a set of scripts that are combined into a single pack and called on demand / schedule. Further, these tests are included in a certain regression of the pack, which contains both automated unit tests and tests of the automation department (we will see how they differ a bit later) and run them before outputting the sprint tasks to the battle. What he gives us think clearly and without my explanation.

It is also allowed to connect integration testing in parallel with unit testing. While the testing team through front-line systems reaches the middle or back systems, testing will be done by more than 70-80%. Those. no downtime associated with the need to edit the code, they will not. This is with regards to the agile team.

Now let's see how things are in teams that work on a cascade principle. The circuit with the included unit testing looks like this:


Here we see that integration testing begins after the end of the modular. This is the main and fundamental difference from the already considered option. Until the task is left with unit testing, integration testing does not begin. Preparing test scripts, test data.

The rest of the process does not change, the same output data and the same buns as in the agile commands.

A little higher, I promised to talk about the difference between automated unit tests and the autotests of the automation team. The difference is very simple and on the surface. In 99%, the automation team automates not a specific refinement, but a process.

Consider the example of a request for information on the card through the Internet Bank The automation team writes a case at the front level (login / go to tab / choose card / press button to request balance). We all know how long such a test will be performed. And at the exit, we get either have information, or it is not. In very rare cases, we will get an understanding of what system / what functionality the error occurred.

What with automated unit tests? Take the same example. The test is written to the integration level, to which the filled contract is entered at the entrance (pulled out of the front-line system), then a transformation occurs, the source system is called, the results are processed, and the response is generated for the receiver system. At every point worth checking. It remains to be verified, but did the source system return all that is necessary? Then you know the solution to this puzzle. Thus, we get not one, but two tests that are performed several times faster and provide comprehensive knowledge in case of an error. We do not spend time on the analysis and analysis of logs.

How to implement unit testing?

Agree that a simple whole team for a long time is a disaster? Therefore, the main benefits of introducing an intermediate stage of unit testing into a team are quite obvious. It remains only to convey it to all participants in the process and those interested in the final result.

First you need to take for granted that not everyone understands what a beast is in general - unit testing. It is necessary to carry out some explanatory work among the team and to present in an accessible way everything that was considered above regarding the differences of such a team from the classical testers.

After the preparatory work, the main task is to achieve the implementation of the unit testing approach, at least in test mode, by allocating a small portion of resources to this.

After several demonstration sprints with a new team formation, the evidence for the effectiveness of this approach will serve:

1. Found at the stage of unit testing defects. (here you can draw analogies with previously found defects of the same level and show the difference in team idle time until the moment of their elimination)
2. The quality of the functionality transferred to the integration testing.
3. The reaction of developers who will speak in a language they understand.
4. In the case of the addition of automation to the unit testing process, ready-made automated unit tests allow in the future to get away from some manual functionality checks.

Conclusion:

As a result, upon completion of all the above implementation operations, unit testing should become an integral part of the process, which will allow:

1. Reduce the number of missing defects.
2. Accelerate the process of bringing new functionality to the end user.
3. Depreciate the interaction process between manual testing and development teams.
4. Create and maintain a cumulative database of low-level autotests that are not dependent on changes in the interface part.