company_banner

Как мы внедряли Agile-testing

    Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения Agile-тестирования в команду. Когда я читала доступные на русском языке статьи про Agile-тестирование и ATDD, у меня сложилось впечатление, что я «не модная», «не по Agile». Казалось, что это некая сложная структура, которая требует включения разработчиков, и до её применения мне ещё «пахать и пахать».


    Какое-то время я жила с этой мыслью, писала в задачи чек-лист проверок при постановке, собирала встречи «feature-team», на которую приглашались PM, QA, Frontend и Backend для обсуждения нюансов задачи до начала реализации.



    Те, кто понимают о чем речь, уже заметили подвох, не правда ли?


    Если погуглить, что такое «Agile testing», то можно встретить предложения по прохождению курсов, парочку статей со взглядами на подход и определение на Википедии:


    «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».

    Не знаю как вы, но я не дочитала это определение с первого раза, на меня напала тоска. На самом деле всё не так сухо. Суть в том, что Agile testing — это такой подход к процессу тестирования, при котором тестировщик гораздо больше участвует на первых этапах проработки задачи и меньше (либо совсем отсутствует) на последних, в отличие от подхода Waterfall.


    Kак был устроен наш флоу работы с задачами


    Стоит сказать, что изначально наша команда работала по трушному SCRUM’у, простите за выражение, что заведомо хорошо совмещается с Agile-тестированием, можно сказать, подразумевает его.


    1. Постановка от заказчика (предположим, ПМ)


    На данном этапе постановка задачи у нас проходила по схеме User Story, Acceptance criterias, Use case. Такая, заведомо Agile, постановка не случайна — это заслуга моей коллеги по юниту, которая уже вводила Agile-тестирование в своей команде. Почему у меня не получилось просто позаимствовать опыт соседней команды, расскажу ниже в статье.


    2. Ревью постановки задачи тестировщиком


    На этом этапе задача проверялась на однозначность, непротиворечивость и полноценность. В моем случае я ещё добавляла сюда же пункт «tests», в котором описывала дополнительные тест-кейсы (например, негативные), которые по формату было неуместно писать в Use case. На тот момент я не полностью осознавала, как пользоваться Acceptance criterias, поэтому просто старалась давать разработчику максимальные вводные по моим будущим проверкам.


    3. Обсуждение задачи всеми заинтересованными или «feature-team»


    Этап выполнялся по необходимости. Если после ревью тестировщик решал, что задача понятна и дополнительные обсуждения не требуются, переходили к четвертому пункту.


    Если этап был необходим, то на встрече вносилась ясность по требованиям, дополнительным работам. Часто задача декомпозировалась, обсуждались условия тестирования при независимой работе фронтенда и бэкенда.


    4. Задача следовала в бэклог, планировалась, выполнялась, выкатывалась и приносила пользу и счастье


    Кажется, всё не так уж и плохо, но есть и что улучшить: как минимум, можно убрать пару лишних этапов, раз уж мы не понимаем зачем они.


    Что сделали, чтобы улучшить


    Испытывая неутолимое желание улучшать, мы с разработчиком прошли внутренний мастер-класс по Agile-тестированию. Оказалось, что для полного соответствия подходу команде надо лишь изменить терминологию и немного подкрутить винтики нашего кастомного велосипеда.
    Ввести подход, наблюдая за командами, в которых он уже есть, недостаточно, необходим блок знаний и этап осознания, который в моём случае дал мастер-класс. Огромным плюсом послужило то, что мы прошли обучение вместе с разработчиком, что я всем настоятельно советую, его помощь сложно переоценить. Вы двое (тестировщик и разработчик) — необходимый и достаточный минимум для начала реализации подхода. Помимо этого, каждая команда и продукт индивидуальны, чтобы подточить этот метод под себя, необходимо, как минимум, попробовать.


    Например, в соседней команде есть опыт полезного применения Unit-тестов с предварительным описанием в инструменте для хранения тест-кейсов и последующей автоматизацией. Наша команда решила сначала определять нужную проверку концептуально, автоматизировать, а уже после автоматически забирать кейсы из кода в инструмент для хранения. У вас, возможно, родится свой способ взаимодействия.


    Я не заявляю, что без особого мероприятия нельзя ввести подход, ни в коем случае. Но необходимо выделить время для понимания, замотивировать команду и начать менять и меняться. Будьте готовы, что не все сразу примут увеличение времени проработки задачи с распростертыми объятиями, мне в этом плане повезло.


    Что почитать на эту тему


    «Agile-тестирование. Обучающий курс для всей команды», Джанет Грегори и Лайза Криспин. Книга недавно вышла в русском переводе и доступна на Озоне.


    Что конкретно изменилось


    1. На наших встречах по уточнению бэклога (PBR) я стала как надоедливый отличник спрашивать обо всём и вся: «А что будет, если сторонний сервис отвалится?», «А что будет, если нам вернется null, а не 0?», «А почему мы вызываем это, а не вон то»?, «А что если нам придут не все данные?», «А что если планету захватят восставшие динозавры?». Шучу, только важные вопросы, никаких «null» и «0».
      Со временем ребята поняли, что в такой дискуссии рождаются несколько неучтённых заранее кейсов, которые теперь они могут предусмотреть. Раньше вопросами вроде «Что будет, если всё развалится?» я задавалась на фазе тестирования, а теперь на фазе постановки.
    2. Вместо пункта «Tests» в задачах мы подробно и осознанно пишем «Acceptance criterias», а также определяем количество и уровни будущих автотестов.
      Для честности стоит сказать, что не в 100% случаев мы заранее знаем уровни автотестов. Есть моменты, когда мы технически не можем это сделать или это занимает больше времени, чем мы имеем на встрече. На практике часто не удаётся действовать кардинально. И это допустимо — что-то придет со временем.
    3. Пункты «Ревью постановки задачи тестировщиком» и «feature-team» мы на данный момент не проводим. Все вопросы решаем на PBR-встречах, поскольку все необходимые люди уже тут, а критерии приёмки обсуждены в процессе.
    4. Тестировщик добавляется в код ревью unit-тестов для подтверждения того, что проверок достаточно.
    5. Вместо обычного тестирования функциональности по окончании процесса разработки проводится прогон автотестов (всех уровней) и только исследовательское тестирование.
      В идеале, конечно, тестирования вовсе тут быть не должно, но на нашей практике мы выяснили, что когда вы вносите изменения в продукт, развиваемый множеством команд, легче и правильнее добавить исследовательское тестирование.

    С какими сложностями столкнулись


    1. Что есть юнит тест


    Мы столкнулись с тем, что мы, QA, не понимаем что именно проверяют unit-тесты и поэтому не доверяем им, а в дань нашей бдительности пишем тесты уровнем выше и стучим каблуком «автоматизировать, нельзя помиловать».


    Как решили:
    Мы с нашим просвещенным в Agile разработчиком (слава ему и его терпению) сели в уголке, и битый час он на пальцах объяснял мне что такое unit-тесты, с чем это едят и почему они не могут проверить ещё «вот эту вот фигулину». В результате наших страданий родилась потрясающая схема сервиса: так нарисовали, что аж сами поняли.



    Одна выделенная стрелочка — один поход — одна проверка в unit тесте


    В итоге спустя пару месяцев, я сама немного пишу юнит тесты и удаляю избыточные проверки на верхних уровнях. Это, конечно, в основном, копипаст, но осознанный!



    Возможно, вы уже хорошо понимаете суть unit-тестов и вам не придется тратить время на этот пункт, но если нет — подкараульте своего разработчика в спокойной обстановке и нападите на него с вопросами.


    2. В текущей реализации не все тесты можно опустить без доработок


    Как решили:
    Убрали лишние датасеты e2e-тестов за счет увеличения количества юнит-тестов.
    Уже реализованные unit-тесты мы пересмотрели, расписали, какие проверки мы от них хотим. После этого, довольно ожидаемо, выяснилось, что части проверок нам недостаёт.
    Определив, что и на каком уровне хотим, поставили задачи на будущее.
    Потренировавшись на том, что уже есть, мы взялись за реальное применение подхода и начали писать проверки на методы, которых еще нет. Это было уже сложнее.


    Выводы


    • Особенность этого подхода в том, что он естественный и растёт из таких вещей, как: «донести ценность до пользователя», «уменьшить ручную работу QA», «обеспечить покрытие». Как именно ты это будешь делать — другое дело, но у этого подхода есть, что тебе предложить и подсказать, какие отмычки применить, чтобы упростить твою жизнь и ничего не потерять.
      К примеру, «Практики Agile testing» — это готовые инструменты для применения, а «Ценности» и «Принципы» — это то, что понятно тестировщику здорового человека, но всё же стоит неоднократно проговорить их себе и своей команде, потому что по опыту знаю: они часто отодвигаются на второй план в режиме высокой нагрузки.


    • Главное в ATDD методологии это то, что прежде, чем что-то делать, надо придумать критерий выполненной работы и критерий того, что работа сделана правильно. Подход, грубо говоря, определяет временной промежуток, на котором вы договариваетесь с командой. Остальное идёт по ходу действия пьесы.



    Например, вы осознаете, что в ваших условиях вы не можете выделить интеграционную прослойку тестов — ничего страшного. Начните с первых этапов подхода: напишите критерии приёмки, определите тесты и их уровни, создайте задачу на светлое будущее. Самый полезный этап здесь — это определение проверок заранее, от ваших дотошных вопросов на этапе постановки задачи — самый быстрый позитивный результат, который докажет вашей команде, что вы не зря тратите их время.


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

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


    По тому, как определить уровень тест-кейса — это отдельный холивар, когда начнете ощущать боль, попробуйте обратиться к литературе. И помните, что практику надо применять там, где она действительно решает проблему, где она облегчает жизнь. Всем добра, удачи и котиков!

    Авито
    281,85
    У нас живут ваши объявления
    Поделиться публикацией

    Комментарии 21

      0
      А реально ли как-то совместить такой принцип Agile testing с досками Agile на youtrack? Программно? Или только вербально можно?
        +2
        Привет! Я думаю, это вполне совместимо )

        Основная работа происходит, когда задача еще лежит в бэклоге. При попадании на доску — это уже задача с описанными критериями, соответственно, переход в InProgress означает и разработку автотестов.
        Если у вас есть колонка «Test», то можно перемещать туда задачи на исследовательское тестирование, либо совсем исключить колонку и пользоваться только «InProgress» — что как раз отражает радикальный Agile testing.

        Насчет программного метода не совсем поняла — не пользовалась этим инструментом. Если я не ответила на ваш вопрос — опишите, пожалуйста, что именно вы бы хотели перенести программно.
          0

          В бэклоге спринта или в основном? И что у вас означает in progress? In development или in testing?

            0
            Имею в виду основной бэклог. То, что взято в спринт — уже должно быть описано.
            Сейчас у нас in progress означает разработку, написание автотестов и их прогон. Колонку in development не используем. In testing — это задачи, готовые к исследовательскому тестированию.

            На самом деле, это скорее вопрос к процессам. Они могут сильно отличаться от наших. Главное, что вы не тестируете руками кейсы, которые полезно было бы заранее покрыть автотестами.
          +1

          Были у вас какие-то трудности с вот этим всем? А то слишком гладко всё выглядит

            +1
            Привет! Я описала несколько проблем в абзаце «С какими сложностями столкнулись» и в комментарии ниже. Кажется, что это основное :)
            +1
            Таки да, поддерживаю предыдущего оратора. Чет многовато терминов и вот этого эльфийского «PBR-встречи», «feature-team» и т.д… Новичку уж точно не разобраться в статье…
            Вопросы:
            Кто был инициатором введения данной методики тестирования и какие стадии согласования вам пришлось пройти? Потому что бывает очень чопорное руководство, до которого не достучаться без предъявления очевидных преимуществ и выгоды…
            Были ли те кто против? И как их лечили?

              0
              Так привыкла к этим терминам, что не заметила, как плотно они вошли в мою речь — у нас давно ввели Scrum )

              В моем случае внедрение подхода прошло спокойно — в соседней команде уже успешно его применяли, и мы это видели. Какой-то формальной процедуры согласования у нас нет. Только если на прохождение мастер-класса. У нас всё просто: если ты хорошо выполняешь свою работу и в срок — то делай её хоть с помощью бубна (немножко утрированно, но в целом подход такой).

              Но, тем не менее, я считаю, что аргументировать преимущества — важно. В чем плюсы:

              1. Увеличение скорости тестирования. Скорость будет увеличиваться за счет уменьшения итераций, поскольку очевидные кейсы будут покрыты автотестами, а крайние моменты будут обсуждены в момент описания задачи, и разработчик сможет их предусмотреть.
              2. В перспективе, активное уменьшение регрессионного тестирования. Регресс автотестами в разы стабильнее и быстрее ручного — думаю, это очевидно.
              3. Стабильный уровень качества. Он также будет зависеть от ваших автотестов, но если бизнес-логика постоянно пересекается — автотесты гарантируют прохождение основных кейсов.

              В моей команде никто не сопротивлялся. Но по опыту ребят из нашего внутреннего комьюнити, скажу, что для разработчика преимущества не всегда очевидны. Мотивировать его можно уменьшением итераций тестирования. Это действительно так (в моем случае — от нуля до двух итераций максимум). Мало кому нравится переключаться обратно на задачу для фикса.
              0
              Можете более подробно описать, каким в итоге стал флоу?
              И если можно сказать, сколько времени примерно проходит от постановки задачи до вашего собрания PBR и до того как вы начнете разработку?

              И если
              Agile testing — это такой подход к процессу тестирования, при котором тестировщик гораздо больше участвует на первых этапах проработки задачи
              , то как это стыкуется с тем, что у вас тестировщик более не проводит ревью постановки и включается только на PBR, т.е позже чем было до этого?
                0
                Конечный флоу:
                1. Постановка задачи.
                2. PBR-встреча, или по-русски: встреча, на которой мы оцениваем задачи, обсуждаем их постановку, задаем друг другу вопросы, проговариваем риски.
                3. Задача следует в бэклог.

                Мне понятно, почему возникло непонимание. Действительно, не все осветила. Спасибо за этот вопрос. Дело в том, что мы решили, что ответственный за постановку задачи теперь тот, кто ее пишет, а не тестировщик. А уже на PBR встрече я (или другой член команды) можем внести коррективы. Это, скорее, про работу команды: можно это и не вводить, но с какого-то момента задача просто стала лучше описываться.
                0
                Гм, непонимание unit тестов.
                Читая статью почему вспоминается Егор Бугаенко с его «экстримистскими» взглядами на роль тестировщика. Как бы помянялся процесс, если бы тестировщик был уровня senior developer, и не только тестировал код, но и принимал участие в его review?
                  0
                  Не знакома со взглядами Егора Бугаенко, но обязательно ознакомлюсь. Спасибо!
                  Но против такого подхода не имею ничего против. Как минимум, если не писать автотесты, то ревьюить точно надо. Так ты уверен, что конкретно тест проверяет, а что он мокает.

                  Насчет код-ревью вопрос спорный. С одной стороны, тратится больше времени (тестировщик будет читать код медленнее, если не рассматривать вариант с senior developer’ом), с другой — повышение компетенции. Почти уверена, что если бы тестировщики участвовали в ревью кода — выхлоп в нахождении багов на этом уровне точно был бы. Остается оценить затраты на обучение тестировщика и применение этого навыка в будущем.
                  А если рассматривать такой вариант, то выгода компании тоже спорная, ведь senior developer в тестировании, как мне видится, будет элементарно дороже.

                  Это вопрос на «поразмышлять» и немного выходит за рамки темы. Кажется, что каждому своё :)
                  0

                  Добрый день.
                  В статье полностью подменено понятие юнит-тестов.
                  То что у вас нарисовано на картинке — это интеграционное тестирование сервисов на бэкэнде.
                  Не ясно почему этим занимается/занимался разработчик. QA у вас не пишет автотесты на бэкэнд?
                  Не могу понять, какая связь между темой статьи и этими тестами? Это какая-то обязательная часть методологии?

                    0
                    Привет!
                    На картинке нарисована не схема тестирования, а общее взаимодействие сервиса. Тесты на ней не обозначены. Мы нарисовали её для общего понимания, что нам нужно будет покрыть.
                    Unit-тесты выделены в статье, так как с пониманием остальных уровней тестов проблем не возникло. То есть мы выделили интеграционные, компонентные, e2e тесты, а вот с пониманием, что можно опустить на юниты, возникли трудности.
                    QA, не пишет unit-тесты, поскольку они зависят от структуры кода. Если у вас есть практика, где такое происходит, то мне было бы интересно узнать, как это работает.
                    Обязательная часть методологии — это практика движения тестов на более низкие уровни. Изначально у нас было много e2e тестов, потому мы их опускаем.
                    Знаю, что на теме уровней автотестов возникает много столкновений. Под юнит-тестом мы понимаем атомарную проверку внутренней работы сервиса :)
                      –1

                      Вы сами себе противоречите.
                      Подпись под картинкой: "Одна выделенная стрелочка — один поход — одна проверка в unit тесте"
                      Практика есть у вас, судя по статье(хотя я спрашивал про интеграцию, а не про юнит, ну да ладно):
                      "В итоге спустя пару месяцев, я сама немного пишу юнит тесты и удаляю избыточные проверки на верхних уровнях"
                      Это тоже очень сильное заявление, которое больше запутывает, чем дает понимания того, что вы делаете и зачем это надо.
                      В отрыве от контекста и без понимания как эффективно(а не тестировщик глазами) мапить юниты на, как минимум, интеграционные говорить о целесообразности такого подхода нельзя(если только мы не говорим о продукте где не предъявляются высокие требования к качеству).

                        0
                        Давайте отвечу на ваш вопрос по частям.

                        «Вы сами себе противоречите.
                        Подпись под картинкой: «Одна выделенная стрелочка — один поход — одна проверка в unit тесте»»
                        — На картинке обозначено взаимодействие сервиса, со стрелочкой лишь пример, как это можно применить. При желании, на ней можно добавить обозначения тестов разных уровней, но я этого не делала и такого смысла в неё не вкладывала.

                        «Это тоже очень сильное заявление, которое больше запутывает, чем дает понимания того, что вы делаете и зачем это надо.»
                        — Я действительно опускала датасеты из e2e-тестов на уровень юнит-тестов. Этот пункт в разделе статьи «как решали сложность в понимании unit-тестов», так мы повышали компетенцию в том, что можно опустить на этот уровень. На новую функциональность, когда кода еще нет, QA unit-тесты не пишет.

                        «Практика есть у вас, судя по статье(хотя я спрашивал про интеграцию, а не про юнит, ну да ладно)».
                        — Я не пишу интеграционные тесты на бэкэнд, поэтому и не приводила их в пример.

                        «В отрыве от контекста и без понимания как эффективно(а не тестировщик глазами) мапить юниты на, как минимум, интеграционные говорить о целесообразности такого подхода нельзя(если только мы не говорим о продукте где не предъявляются высокие требования к качеству).»
                        — Как маппить автотесты разного уровня — тема для отдельной статьи, моя статья на этот вопрос не отвечает, а рассказывает о процессах внедрения подхода agile-тестирования.

                        Хорошего дня!
                    0
                    Harddreamer Спасибо за статью, как раз очень актуальна для меня сейчас.
                    Подскажите, как Вы ведете документирование тестов на разных уровнях? Пользуетесь ли TMS для этих целей?
                      0
                      Привет! Да, мы используем TMS. Правда, у нас свой собственный инструмент. Отдельная команда подпиливает его для наших нужд.
                      Мы стараемся хранить тест-кейсы всех уровней в одном месте, чтобы видеть общую картину. При создании (ручном или автоматическом) мы указываем тип тесткейса — e2e/component/integration/unit, там же у нас видно покрытие. Пропорции пирамид смотрим уже в Grafana.
                      На данный момент столкнулись с тем, что некоторые unit тесты не содержат никакой бизнес-логики, и вопрос об их хранении в общем месте — спорный. Это уже на ваше усмотрение, зависит от цели хранения тесткейсов.

                      Некоторые другие TMS, насколько я знаю, тоже имеют поле «Тип тесткейса». Например, PractiTest, либо можно пользоваться любой другой удобной маркировкой.
                      Если захотите узнать чуть больше про нашу тестохранилку, то советую почитать статью моего коллеги Вадима Шашина What Does Our Test Case Management System Look Like?
                      0
                      Чем же отличается тестирование / QC / QA в рамках Agile-методов от механик прочих методологий (любые на ваш выбор)?
                      Интересно узнать особенности, которые применяются именно в Agile, при этом не применяются в прочих методологиях по каким-либо причинам: неэффективность по трудозатратам для достижения полезности, невозможность исполнения, нецелесообразность (бесполезность) и т.д.
                        0
                        В статье я сравнила подходы Waterfall и Agile. Agile в нашем случае сработал лучше: мы научились предотвращать ошибки на более ранних этапах и избавили тестировщика от монотонной работы. По времени, конечно, ускорились не сразу. Вначале и вовсе замедлились. Но мы понимали, что этот подход увеличивает скорость в долгосрочной перспективе — за счет хорошего покрытия автотестами.
                        Сравнить с какими-то другими методологиями я не могу — их не использовала. Если напишите пример из методики, которая вас интересует, или применение таких же практик, в другом подходе, то смогу вам ответить точнее :)
                          0
                          Так чем же отличается тестирование / QC / QA в рамках Agile-методов от механик знакомого вам подхода Waterfall? Дополню предыдущий комментарий ~примером ожидаемой трактовки на каждое отличие: «X следует использовать в Agile и не нужно использовать в Waterfall потому, что <…>»

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое