How we implemented agile testing

    Hello! My name is Alyona Isakova, I am a leading tester in Avito, and I want to tell you about my experience in introducing Agile testing to the team. When I read articles on Agile testing and ATDD available in Russian, I had the impression that I was "not fashionable," "not about Agile." It seemed that this was some kind of complex structure that required the inclusion of developers, and before it was applied, I still had to "plow and plow."

    For a while I lived with this idea, wrote a checklist of tasks during setting into tasks, collected meetings of the “feature-team”, to which PM, QA, Frontend and Backend were invited to discuss the nuances of the task before implementation.

    Those who understand what they’re talking about have already noticed the catch, aren't they?

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

    "Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding. "

    I don’t know about you, but I didn’t finish reading 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 such an approach to the testing process, in which the tester is much more involved in the first stages of the task and less (or completely absent) in the latter, unlike the Waterfall approach.

    How was our task flow arranged

    It is worth saying that initially our team worked on the rigorous SCRUM, sorry for the expression, which obviously goes well with Agile testing, you can say it implies it.

    1. Statement from the customer (assume PM)

    At this stage, the statement of the problem was carried out according to the scheme User Story, Acceptance criterias, Use case. Such a statement, obviously of Agile, is not accidental - it is a merit of my colleague in the unit, who has already introduced Agile testing in her team. Why I couldn’t just borrow the experience of a neighboring team, I’ll tell you later in the article.

    2. Review of the statement of the problem by the tester

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

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

    The stage was carried out as necessary. If after the review, the tester decided that the task is clear and additional discussions are not required, we proceeded to the fourth paragraph.

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

    4. The task followed in a backlog, was planned, carried out, rolled out and brought benefit 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 have been done to improve

    Feeling an insatiable desire to improve, the developer and I passed an internal master class on Agile testing. It turned out that in order to fully comply with the approach, the team only needs to change the terminology and tighten the screws of our custom bike a little.
    Introducing the approach, observing the teams in which it already exists, is not enough, you need a block of knowledge and a stage of awareness, which in my case was given by a master class. A huge plus was the fact that we went through training with the developer, which I strongly advise everyone, it is difficult to overestimate his help. You two (tester and developer) are a necessary and sufficient minimum to start implementing the approach. In addition, each team and product is individual, in order to refine this method for yourself, you must at least try.

    For example, in a neighboring team there is experience in the useful use of Unit tests with a preliminary description in a tool for storing test cases and subsequent automation. Our team decided to first determine the necessary verification conceptually, automate it, and after that automatically select the cases from the code into a 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 no case. But you need to take time to understand, motivate the team and begin to change and change. Be prepared that not everyone will immediately accept the increase in the time spent on the 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 the backlog (PBR), I became like an annoying excellent pupil asking everything and everything: “What will happen if the third-party service falls off?”, “What will happen if we return null, not 0?”, “A why do we call this, and not over there? ”,“ And what if we don’t get all the data? ”,“ What if the planet is captured by rebellious dinosaurs? ” Just kidding, only important questions, no “null” and “0”.
      Over time, the guys realized that in such a discussion, several cases unaccounted for in advance are born that they can now foresee. Previously, questions like “What happens if everything falls apart?” I wondered in the testing phase, and now in the setting phase.
    2. Instead of the “Tests” item in tasks, we write “Acceptance criterias” in detail and consciously, and also determine the number and levels of future autotests.
      For honesty, it is worth saying that not in 100% of cases we know the levels of autotests in advance. There are times when we technically cannot do this or it takes longer than we have at the meeting. In practice, it is often not possible to act dramatically. And this is permissible - something will come with time.
    3. The items “Review of the statement of the problem by the tester” and “feature-team” we are not currently conducting. We resolve all issues at PBR meetings, since all the necessary people are already here, and the acceptance criteria are discussed in the process.
    4. The tester is added to the unit test review code to confirm that there are enough checks.
    5. Instead of the usual testing of functionality, at the end of the development process, autotests (at all levels) are run and only research testing is carried out.
      Ideally, of course, testing should not be there at all, but in our practice we have found that when you make changes to a product developed by many teams, it is easier and more correct to add research testing.

    What difficulties did you face?

    1. What is a unit test

    We are faced with the fact that we, QA, do not understand what unit tests are testing and therefore do not trust them, and in tribute to our vigilance, we write tests a level higher and with a knocking heel “to automate, you can’t have mercy”.

    How they decided:
    We, with our Agile-educated developer (thank him and his patience), sat in the corner, and for the past hour he explained to me on the fingers what unit tests are, what they eat with and why they cannot check yet “this one figulin. " As a result of our suffering, an amazing service scheme was born: they drew it in such a way that they themselves understood.

    One selected arrow - one trip - one check in the unit test

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

    Perhaps you already understand the essence of unit tests well and you don’t have to spend time on this item, but if not, subcautify your developer in a calm environment and attack him with questions.

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

    How they decided:
    They removed the extra datasets of e2e tests by increasing the number of unit tests.
    We have already revised the unit tests that have been implemented, we have written down what checks we want from them. After that, quite expectedly, it turned out that we were missing 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 real application of the approach and began to write checks on methods that are not yet available. It was already harder.


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

    • The main thing in the ATDD methodology is that before you do something, you need to come up with a criterion for the work done and a criterion for the work to be done correctly. Roughly speaking, the approach determines the time period at which you agree with the team. The rest goes along with the play.

    For example, you realize that in your conditions you cannot distinguish the integration layer of tests - that's okay. Start with the first steps of the approach: write down the acceptance criteria, define the tests and their levels, create a task for a brighter future. The most useful step here is to determine 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.

    • В целом, подход Agile-тестирования и предложенные в нем ценности, принципы и практики вытекают из вполне очевидных вещей, как говорил мой любимый преподаватель по высшей алгебре: «А вот здесь надо применить здравый смысл». Этому и стоит следовать, и не только в тестировании.

    Однажды, в разгаре обсуждения, мы с командой поняли, что пишем проверки на слишком уж много условий, и это нас надоумило на вопрос: «А точно ли на тот параметр мы делаем вызов метода?». Оказалось, что постановку задачи можно в корне упростить, вызывать саму сущность, а не логику выше уровнем от неё. То есть условий, когда у нас есть зависимая сущность, но нет самой сущности, не существует. Это упростило нам жизнь.

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

    Also popular now: