Hello! My name is Alena Isakova, I am the leading tester in Avito, and I want to tell you about my experience in introducing Agile testing into the team. When I read articles about Agile testing and ATDD available in Russian, I got the impression that I was “not fashionable”, “not according to Agile”. It seemed that it was a kind of complex structure that required the inclusion of developers, and before applying it I still have to “plow and plow”.

For a while I lived with this thought, wrote a check-list of checks for tasks when setting, collected “feature-team” meetings, to which PM, QA, Frontend and Backend were invited to discuss the nuances of the task before implementation.

Those who understand what they mean, have already noticed a catch, is not it?

If you google what “Agile testing” is, you can find suggestions for passing courses, a couple of articles with views on the approach and definition on Wikipedia:

“Agile software development. The agile testing team has been working on a sustainable pace. Coding.

I don’t know about you, but I didn’t read this definition the first time, I was attacked by longing. In fact, everything is not so dry. The bottom line is that Agile testing is an approach to the testing process in which the tester is much more involved in the first stages of working out the task and less (or completely absent) in the latter, unlike the approach of Waterfall.

How our tasks flow was arranged

It is worth saying that initially our team worked on the trump SCRUM, sorry for the expression, which obviously goes well with Agile-testing, one might say, implies it.

1. Statement from the customer (suppose PM)

At this stage, we set the task according to the User Story, Acceptance criterias, Use case scheme. This, obviously Agile, setting is not accidental - it is a merit of my fellow unit, which has already introduced Agile testing in its team. Why I didn’t manage to just borrow the experience of the neighboring team, I’ll tell you later in the article.

2. Review of the problem statement by the tester

At this stage, the task was checked for uniqueness, consistency and usefulness. In my case, I also added the “tests” item, in which I described additional test cases (for example, negative ones), which were inappropriate for writing in Use case. At that time, I was not fully aware of how to use Acceptance criterias, so I just tried to give the developer maximum input on my future checks.

3. Discussion of the task by all interested or “feature-team”

The stage was performed as necessary. If, after the review, the tester decided that the task was clear and no further discussion was required, proceed to the fourth paragraph.

If the stage was necessary, then the meeting brought clarity on the requirements, additional work. Often the task was decomposed, the testing conditions for the independent work of the frontend and backend were discussed.

4. The task followed in backlog, planned, executed, rolled out and brought benefits and happiness

It seems that everything is not so bad, but there is something to improve: at least, you can remove a couple of extra steps, since we do not understand why they are.

What was done to improve

Feeling an insatiable desire to improve, we went through an internal master class on Agile testing with the developer. It turned out that in order to fully comply with the approach of the team, it is only necessary to change the terminology and twist the cogs of our custom bike a little.
Entering an approach, observing the teams in which he already has is not enough, a knowledge block and an awareness stage, which in my case was given by the master class, is necessary. The great advantage was the fact that we were trained along with the developer, which I strongly advise everyone, its help is difficult to overestimate. You two (tester and developer) - a necessary and sufficient minimum to start implementing the approach. In addition, each team and product is individual, in order to sharpen this method for yourself, you must at least try.

For example, in the next team there is an experience of useful application of Unit tests with a preliminary description in the tool for storing test cases and subsequent automation. Our team decided to first determine the necessary verification conceptually, to automate, and then after automatically take the cases from the code into the storage tool. You may have your own way of interacting.

I do not declare that without a special event it is impossible to introduce an approach, in any case. But it is necessary to take time to understand, motivate the team and start changing and changing. Be prepared that not everyone will immediately accept an increase in the time it takes to work on a task with open arms, I was lucky in this regard.

What to read on this topic

“Agile testing. Training course for the whole team ”, Janet Gregory and Lisa Crispin. The book has recently been published in Russian translation and is available on Ozone.

What exactly has changed

1. At our meetings to clarify backlog (PBR), I became like an annoying high achiever to ask everything and everything: “What if the third-party service falls off?”, “What happens if we get null, not 0?”, “A Why do we cause this, but not that ”?,“ And what if not all the data comes to us? ”,“ What if the planet is taken over by rebel dinosaurs? ”. Just kidding, just important questions, no “null” and “0”.
   Over time, the guys realized that in such a discussion several unaccounted cases are born that they can now foresee. Previously, questions like "What will happen if everything falls apart?" I asked myself during the testing phase, and now during the production phase.
2. Instead of the “Tests” item in the tasks, we write in detail and consciously “Acceptance criterias”, and also determine the number and levels of future autotests.
   For honesty, it’s worth saying that not in 100% of cases we know in advance the autotest levels. There are times when we technically cannot do this or it takes longer than we have at the meeting. In practice, often fails to act dramatically. And this is permissible - something will come with time.
3. We currently do not carry out the “Testing Problem Review” and “feature-team” items. All issues are resolved at PBR meetings, since all the necessary people are already there, and acceptance criteria are discussed in the process.
4. The tester is added to the code with unit-test reviews to confirm that there are enough checks.
5. Instead of the usual functionality testing, at the end of the development process, the autotests are run (all levels) and only the research testing.
   Ideally, of course, there should be no testing at all here, but in our practice we found out that when you make changes to a product developed by a multitude of teams, it is easier and more correct to add research testing.

What difficulties faced

1. What is a unit test?

We are faced with the fact that we, QA, do not understand what unit-tests are tested for and therefore do not trust them, but in order to keep our guardianship we write tests a level higher and knock with a heel “to automate, we cannot pardon”.

As decided:
We sat down in the corner with our enlightened Agile developer (thank him and his patience), and he spent a good hour explaining to me what unit-tests are, what they eat and why they can’t check “this one here.” As a result of our sufferings, an amazing service scheme was born: they drew it so much that they themselves understood.

One highlighted arrow - one trip - one check in unit test

As a result, after a couple of months, I write a little unit tests myself and remove redundant checks at the upper levels. This, of course, is basically copy-paste, but deliberate!

You may well understand the essence of unit-tests and you will not have to spend time on this item, but if not, wait for your developer in a calm atmosphere and attack him with questions.

2. In the current implementation, not all tests can be omitted without modifications.

As decided:
Removed extra datasets e2e-tests by increasing the number of unit tests.
Already implemented unit-tests we reviewed, painted, what checks we want from them. After that, quite predictably, it turned out that we lacked some of the checks.
Having determined what and at what level we want, we set tasks for the future.
Having trained on what is already there, we took up the actual application of the approach and began to write tests on methods that are not yet available. It was already harder.

findings

• The peculiarity of this approach is that it is natural and grows from such things as: “convey value to the user”, “reduce the manual work of QA”, “provide coverage”. How exactly will you do it - is another matter, but this approach has something to offer you and suggest which key picks to use in order to simplify your life and not lose anything.
  For example, “Agile testing practices” are ready-made tools for use, and “Values” and “Principles” are what the tester of a healthy person understands, but still it’s worth repeatedly to speak them to yourself and your team, because I know from experience : they are often relegated to high loading.

  
  

• The main thing in the ATDD methodology is that, before doing something, you need to come up with a criterion of the work done and a criterion that the work is done correctly. Approach, roughly speaking, determines the time period in which you agree with the team. The rest goes along with the play.

  
  

For example, you realize that in your conditions you can not distinguish the integration layer of tests - nothing terrible. Start from the first stages of the approach: write the acceptance criteria, define the tests and their levels, create a task for a bright future. The most useful step here is to define the checks in advance, from your meticulous questions at the stage of setting the task - the fastest positive result that will prove to your team that you are not wasting their time.

• In general, the approach of Agile-testing and the values, principles and practices proposed in it follow from quite obvious things, as my favorite teacher of higher algebra said: “And here you need to apply common sense.” This should be followed, and not only in testing.

One day, at the height of the discussion, we with the team realized that we were writing checks for too many conditions, and this put us up to the question: “Is it possible that we make a method call to that parameter?”. It turned out that the formulation of the problem can be simplified, causing the essence itself, and not the logic above the level of it. That is, the conditions when we have a dependent entity, but there is no entity itself, it does not exist. It simplified our lives.

By how to determine the level of the test case - this is a separate holivar, when you start to feel pain, try to refer to the literature. And remember that the practice should be applied where it really solves the problem, where it makes life easier. All good luck and seals!