Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения 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-тестирование. Обучающий курс для всей команды», Джанет Грегори и Лайза Криспин. Книга недавно вышла в русском переводе и доступна на Озоне.
Что конкретно изменилось
- На наших встречах по уточнению бэклога (PBR) я стала как надоедливый отличник спрашивать обо всём и вся: «А что будет, если сторонний сервис отвалится?», «А что будет, если нам вернется null, а не 0?», «А почему мы вызываем это, а не вон то»?, «А что если нам придут не все данные?», «А что, если планету захватят восставшие динозавры?». Шучу, только важные вопросы, никаких «null» и «0».
Со временем ребята поняли, что в такой дискуссии рождаются несколько неучтённых заранее кейсов, которые теперь они могут предусмотреть. Раньше вопросами вроде «Что будет, если всё развалится?» я задавалась на фазе тестирования, а теперь на фазе постановки. - Вместо пункта «Tests» в задачах мы подробно и осознанно пишем «Acceptance criterias», а также определяем количество и уровни будущих автотестов.
Для честности стоит сказать что не в 100% случаев мы заранее знаем уровни автотестов. Есть моменты, когда мы технически не можем это сделать или это занимает больше времени, чем мы имеем на встрече. На практике часто не удаётся действовать кардинально. И это допустимо — что-то придет со временем. - Пункты «Ревью постановки задачи тестировщиком» и «feature-team» мы на данный момент не проводим. Все вопросы решаем на PBR-встречах, поскольку все необходимые люди уже тут, а критерии приёмки обсуждены в процессе.
- Тестировщик добавляется в код ревью unit-тестов для подтверждения того, что проверок достаточно.
- Вместо обычного тестирования функциональности по окончанию процесса разработки проводится прогон автотестов (всех уровней) и только исследовательское тестирование.
В идеале, конечно, тестирования вовсе тут быть не должно, но на нашей практике мы выяснили, что когда вы вносите изменения в продукт, развиваемый множеством команд, легче и правильнее добавить исследовательское тестирование.
С какими сложностями столкнулись
1. Что есть юнит тест
Мы столкнулись с тем, что мы, QA, не понимаем что именно проверяют unit-тесты и поэтому не доверяем им, а в дань нашей бдительности пишем тесты уровнем выше и стучим каблуком «автоматизировать, нельзя помиловать».
Как решили:
Мы с нашим просвещенным в Agile разработчиком (слава ему и его терпению) сели в уголке, и битый час он на пальцах объяснял мне что такое unit-тесты, с чем это едят и почему они не могут проверить ещё «вот эту вот фигулину». В результате наших страданий родилась потрясающая схема сервиса: так нарисовали, что аж сами поняли.
Одна выделенная стрелочка — один поход — одна проверка в unit тесте
В итоге спустя пару месяцев, я сама немного пишу юнит тесты и удаляю избыточные проверки на верхних уровнях. Это, конечно, в основном, копипаст, но осознанный!
Возможно, вы уже хорошо понимаете суть unit-тестов и вам не придется тратить время на этот пункт, но если нет — подкараульте своего разработчика в спокойной обстановке и нападите на него с вопросами.
2. В текущей реализации не все тесты можно опустить без доработок
Как решили:
Убрали лишние датасеты e2e-тестов за счет увеличения количества юнит-тестов.
Уже реализованные unit-тесты мы пересмотрели, расписали, какие проверки мы от них хотим. После этого, довольно ожидаемо, выяснилось, что части проверок нам недостаёт.
Определив, что и на каком уровне хотим, поставили задачи на будущее.
Потренировавшись на том, что уже есть, мы взялись за реальное применение подхода и начали писать проверки на методы, которых еще нет. Это было уже сложнее.
Выводы
-
Особенность этого подхода в том, что он естественный и растёт из таких вещей, как: «донести ценность до пользователя», «уменьшить ручную работу QA», «обеспечить покрытие». Как именно ты это будешь делать — другое дело, но у этого подхода есть, что тебе предложить и подсказать, какие отмычки применить, чтобы упростить твою жизнь и ничего не потерять.
К примеру, «Практики Agile testing» — это готовые инструменты для применения, а «Ценности» и «Принципы» — это то, что понятно тестировщику здорового человека, но всё же стоит неоднократно проговорить их себе и своей команде, потому что по опыту знаю: они часто отодвигаются на второй план в режиме высокой нагрузки. -
Главное в ATDD методологии это то, что прежде, чем что-то делать, надо придумать критерий выполненной работы и критерий того, что работа сделана правильно. Подход, грубо говоря, определяет временной промежуток, на котором вы договариваетесь с командой. Остальное идёт по ходу действия пьесы.
Например, вы осознаете, что в ваших условиях вы не можете выделить интеграционную прослойку тестов — ничего страшного. Начните с первых этапов подхода: напишите критерии приёмки, определите тесты и их уровни, создайте задачу на светлое будущее. Самый полезный этап здесь — это определение проверок заранее, от ваших дотошных вопросов на этапе постановки задачи — самый быстрый позитивный результат, который докажет вашей команде, что вы не зря тратите их время. -
В целом, подход Agile-тестирования и предложенные в нем ценности, принципы и практики вытекают из вполне очевидных вещей, как говорил мой любимый преподаватель по высшей алгебре: «А вот здесь надо применить здравый смысл». Этому и стоит следовать, и не только в тестировании.
Однажды, в разгаре обсуждения, мы с командой поняли, что пишем проверки на слишком уж много условий, и это нас надоумило на вопрос: «А точно ли на тот параметр мы делаем вызов метода?». Оказалось, что постановку задачи можно в корне упростить, вызывать саму сущность, а не логику выше уровнем от неё. То есть условий, когда у нас есть зависимая сущность, но нет самой сущности, не существует. Это упростило нам жизнь.
По тому, как определить уровень тесткейса — это отдельный холивар, когда начнете ощущать боль, попробуйте обратиться к литературе. И помните, что практику надо применять там, где она действительно решает проблему, где она облегчает жизнь. Всем добра, удачи и котиков!
Автор: Harddreamer
