Хабрахабр

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

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

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

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

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

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. «Agile testing is a software testing practice that follows the principles of agile software development. Specification by example is used to capture examples of desired and undesired behavior and guide coding».

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

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

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

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

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-тесты мы пересмотрели, расписали, какие проверки мы от них хотим. Это было уже сложнее.

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть