Get best of the week

How to improve the performance of agile teams through testing

Agile development is aimed at delivering new features quickly and with the right frequency, ensuring a constant stream of changes. A flexible approach allows the team to keep a high pace, but because of this, the quality of the code and the stability of the product often suffer. How to solve this problem without driving the team into a tight framework and without depriving it of the advantages of agile methods? Help comes from testers. My name is Denis Dubovoi, I head the testing department in the big data directorate of X5 Retail Group, and in this article I will tell how the appearance of testers helped to improve the quality of work of our developers.



Making rules through testing


Agile teams often neglect quality. This is partly due to the fact that traditional testing methodologies do not fit into a “flexible” context, partly due to the priority of speed over quality. The primary task of the agile team is to quickly implement the functions that a business customer needs. This is especially true at the stage of formation of a product, when its functionality is determined literally by trial and error, and developers need to quickly rebuild the product for current requests. In such a situation, the team often decides this way: we will call the tester later, when we do the MVP / first working version / we learn Zen - because it simply does not understand how to organize flexible testing. The result is often disruption in delivery times, errors on the demo and, worst of all, in the PROM environment.

In our case, the situation was very similar: the X5 Retail Group Big Data Product Development Department has existed for 2 years, and at first the quality of the products was maintained only by the developers themselves - there was no dedicated QA specialist role, and the testing department and the first tester in the product appeared only a year ago, when the products had already started.

Today, there are already 15 people in the testing department: 11 testers accompany the products in teams, two people develop the direction of load testing, and two more - the direction of test automation. In many product teams, testers have become a catalyst for important changes: their arrival streamlined the development process and improved release stability. To do this, we connected testers to already working teams according to the following scheme:

1. Dive into the process


At the first stage, we need to understand how the team is working now, how roles are distributed in it, and how information is exchanged. The tester begins to help with testing, more in the form of "quality control", simultaneously evaluating the maturity of the team and the processes in the team - for this there is a small "heat map" of maturity, an example of which can be seen below. On it you can see how various directions are developed (development, testing, DG, DevOps, support) in each of our products.


Maturity Heat Map

Testers collect the assessment of process maturity together with the developers, evaluating the set of technological and methodological practices used by the team. As a result, we can see from the heat map what can be improved and in which area - for example, to develop the practice of Unit tests in development or to automate API checks in testing - for each stage of a product’s life (prototype, pilot, industrial), its own set of practices is recommended.

2. We make recommendations for improvement




Having figured out how the team lives, you can think over the first recommendations for improving its work. Here we adhere to the following logic: testers are not a dedicated function responsible for a specific area, we are part of the team and can influence the whole process. In order to facilitate the launch of improvements, we start with the basic things:

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • We fix the sprint stages and one of the critical points - the point “code freeze”.

We looked into the stages before testing and a little into the testing itself, but there is also a technical part with maintaining test benches and working with test data and an industrial part with product support. Testers are somehow involved at all these stages - we try to raise T-Shape specialists who see the entire production process, and not just their immediate function.

3. We present our improvements to team leaders and stakeholders, focusing on what problems these improvements will solve


The process will be easier if you enlist the support of the team. It’s important to “sell” your idea, to show what profit your proposed changes will bring. For example, the acceptance criteria that we mentioned above may look like additional work for the analyst, but when the team understands what time savings it will receive - and this from hours to days, which may take to refine the task - it takes the improvement much easier.

In some cases, you can act through the owner of the product. For example, the product lacks monitoring (for example, technical, with logs and beautiful graphs) and there is no time to configure, because this is not a product task. In this case, you can contact the product and explain exactly what benefits it will receive from monitoring (it will not become more stable right away, but the speed of problem localization will increase), and ask him to allocate resources for this.
In parallel with the standardization of work in product teams, testing approaches are being developed that ensure the quality of products, for example, evaluating and preparing the necessary volumes of test data, developing a test model, forming points for future automation, etc.

There is always a chance that the team will not accept the proposed changes, no matter how reasonable they may seem to you. In each individual case, it is necessary to formulate your own approaches and look for an individual way of persuasion. The products are very different, and the approaches that work in one product do not work at all in another.

Many teams are confident that they are able to organize their work themselves, and sometimes this is true. There were cases when our participation came down to recommending the main points of verification, and then the team perfectly implemented everything at the code level, and we just stayed nearby, always ready to help. But more often it happens differently: our employee comes to the team, and the developers jokingly start to “cry” from the defects found by the tester, rejoicing that the defects were found before the demo or industrial release.

What changed


Changes in product teams went differently and affected different aspects of the process. In one of the teams, testing at first became a bottleneck: it took time, and not everyone understood what was happening at this stage. As an experiment, we connected developers to running tests, as a result of which they were able to experience the work of testers and even see the product as a whole - not a separate reporting function, for example, but the whole way from user authorization in the product and conducting business operations to the end - unloading report. So we strengthened the involvement of the whole team, made the testing process transparent and showed the importance of this action, and the practice described above became regular.

In another product, the release cycle has changed with our help. Initially, it was arranged that the results of the sprint went into testing on Friday afternoon, and on Monday the product already reached the customer. The very end of Friday and only the beginning of Monday remained for testing and fixing critical errors, and as a result, the new version often came out “raw” or the developers had to urgently fix bugs on the weekend. After a couple of difficult delivery shifts, the team still postponed the delivery of the sprint to Wednesday (did not reduce the sprint length, but simply shifted the schedule by two days). Now the team has time to check and correct the delivery in a relaxed atmosphere.



The final decision, whether to change or not, remains with the team: it is she who is responsible for the product and its output, which is why she chooses the most convenient option for herself. The goal of our work is not to impose our approaches on programmers, but to give maximum information about possible risks and offer improvements and actions suitable for the product.

What our testing department managed to do over the past year:

  • Regular functional testing has appeared in 7 products of the X5 Retail Group Big Data Department, 2 of them have reached stable releases in PROM without critical comments. Organized regular load testing of 3 products.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

Changes are always complex, but they are necessary if we root for our products. And it is testers who can make a significant contribution to ensuring the quality of products.
In the following articles, my colleagues and I will talk about how we test specific products, about choosing a testing strategy, about tools (for example, Allure Enterprise edition - a convenient tool for managing testing, reporting and even managing autotests), and how to implement automated tests in pipeline and what development options we see (Test Driven Development, if you thought about it, this is only one of the possible options).

More articles:


All Articles