Разработка по методологии Agile нацелена на то, чтобы выдавать новые фичи быстро и с нужной периодичностью, обеспечивая постоянный поток изменений. Гибкий подход позволяет команде держать высокий темп, но из-за этого нередко страдает качество кода и стабильность продукта. Как решить эту проблему, не загоняя команду в жесткие рамки и не лишая ее преимуществ agile-методов? Помощь приходит со стороны тестировщиков. Меня зовут Денис Дубовой, я руковожу отделом тестирования в дирекции больших данных X5 Retail Group, и в этом материале я расскажу, как появление тестировщиков помогло повысить качество работы наших разработчиков.
Команды, работающие по agile-методологии, часто пренебрегают качеством. Отчасти это происходит из-за того, что традиционные методологии тестирования не вписываются в «гибкий» контекст, отчасти из-за приоритетов скорости над качеством. Первоочередная задача agile-команды — оперативно реализовывать функции, которые нужны бизнес-заказчику. Это особенно актуально на стадии становления продукта, когда его функционал определяется буквально путем проб и ошибок, и разработчикам нужно быстро перестраивать продукт под текущие запросы. В такой ситуации команда часто решает так: позовем тестировщика потом, когда сделаем MVP/первую рабочую версию/познаем дзен — потому что просто не понимает, как организовать гибкое тестирование. В итоге часто получаются срывы сроков поставки, ошибки на демо и, самое страшное, в ПРОМ-среде.
В нашем случае была очень похожая ситуация: Управление разработки продуктов больших данных X5 Retail Group существует уже 2 года, и на первых порах качество продуктов поддерживалось только силами самих разработчиков — не было выделенной роли QA-специалиста, а отдел тестирования и первый тестировщик в продукте появились только год назад, когда продукты уже успели стартовать.
Сегодня в отделе тестирования уже 15 человек: 11 тестировщиков сопровождают продукты в командах, два человека развивают направление нагрузочного тестирования и еще два – направление автоматизации тестирования. Во многих продуктовых командах тестировщики стали катализатором важных изменений: их приход упорядочил процесс разработки и повысил стабильность релизов. Для этого мы подключали тестировщиков к уже работающим командам по следующей схеме:
На первом этапе нам надо понять, как сейчас работает команда, как в ней распределяются роли и как происходит обмен информацией. Тестировщик начинает помогать с тестированием, больше в виде «контроля качества», попутно оценивая зрелость команды и процессов в команде – для этого есть своя небольшая «тепловая карта» зрелости, пример которой можно увидеть ниже. На ней можно видеть, насколько развиты различные направления (разработка, тестирование, DG, DevOps, поддержка) в каждом из наших продуктов.
Тепловая карта оценки зрелости
Оценку зрелости процессов тестировщики собирают вместе с разработчиками, оценивая набор технологических и методических практик, используемых командой. В итоге по тепловой карте мы можем увидеть, что и на каком участке можно улучшить – например развить практику Unit-тестов в разработке или автоматизировать проверки API в тестировании – для каждой стадии жизни продукта (прототип, пилот, пром) рекомендуется свой набор практик.
Разобравшись, как живет команда, можно продумать первые рекомендации по улучшению ее работы. Тут мы придерживаемся следующей логики: тестировщики – не выделенная функция, отвечающая за определенный участок, мы часть команды и можем влиять на весь процесс. Для того, чтобы облегчить запуск улучшений, начинаем с базовых вещей:
Это мы заглянули в этапы до тестирования и немного в само тестирование, а есть еще техническая часть с ведением тестовых стендов и работой с тестовыми данными и промышленная с сопровождением продукта. Тестировщики так или иначе задействованы на всех этих этапах – мы стараемся растить T-Shape специалистов, которые видят весь процесс производства, а не только свою непосредственную функцию.
Процесс пойдёт проще, если заручиться поддержкой команды. Важно «продать» свою идею, показать, какой профит принесут предложенные вами изменения. Например, критерии приемки, которые мы упоминали выше, могут выглядеть как дополнительная работа для аналитика, но когда команда понимает, какую экономию времени она получит – а это от часов до дней, которые могут уходить на уточнение задачи, – то принимает улучшение намного легче.
В некоторых случаях можно действовать через владельца продукта. Например, продукту не хватает мониторинга (допустим, технического, с логами и красивыми графиками) и на настройку нет времени, ведь это не продуктовая задача. В таком случае можно обратиться к продакту и пояснить, какие именно выгоды он получит от мониторинга (стабильнее сразу не станет, но вырастет скорость локализации проблем), и попросить его выделить на это ресурсы.
Параллельно со стандартизацией работы в продуктовых командах идёт проработка подходов к тестированию, которые обеспечивают качество продуктов, например, оценка и подготовка необходимых объемов тестовых данных, проработка тестовой модели, формирование точек будущей автоматизации и т.д.
Всегда есть вероятность, что команда не примет предлагаемые изменения, какими бы разумными они вам ни казались. В каждом отдельном случае необходимо формировать свои подходы и искать индивидуальный способ убеждения. Продукты очень разные, и подходы, работающие в одном продукте, совсем не работают в другом.
Многие команды уверены, что способны сами организовать свою работу, и иногда это действительно так. Были случаи, когда наше участие сводилось к рекомендации основных точек проверки, и дальше команда прекрасно все реализовывала на уровне кода, а мы просто оставались рядом, всегда готовые помочь. Но чаще происходит по-другому: в команду приходит наш сотрудник, и разработчики в шутку начинают «плакать» от найденных тестировщиком дефектов, радуясь при этом, что дефекты найдены до демо или промышленного релиза.
Перемены в продуктовых командах шли по-разному и затронули разные стороны процесса. В одной из команд тестирование сначала стало узким местом: оно требовало времени, и не все понимали, что же происходит на этом этапе. В виде эксперимента мы подключили разработчиков к запуску тестов, в результате чего они смогли прочувствовать работу тестировщиков и даже увидеть продукт в целом – не отдельную функцию построения отчета, например, а весь путь от авторизации пользователя в продукте и проведения бизнес-операций до итога – выгрузки отчета. Так мы усилили вовлеченность всей команды, сделали прозрачным процесс тестирования и показали важность этого действия, а описанная выше практика стала регулярной.
В другом продукте с нашей помощью изменился релизный цикл. Изначально было устроено так, что результаты спринта уходили в тестирование в пятницу после обеда, а в понедельник продукт уже попадал к заказчику. На тестирование и исправление критических ошибок оставался самый конец пятницы и лишь начало понедельника, и в итоге новая версия нередко выходила «сырой» или же разработчикам приходилось срочно фиксить баги в выходные. После пары сложных сдвигов поставки команда все же перенесла сдачу спринта на среду (не уменьшила длину спринта, а просто сдвинула график на два дня). Теперь у команды есть время проверить и исправить поставку в спокойной обстановке.
Окончательное решение, меняться или нет, остается за командой: именно она отвечает за продукт и его выход, поэтому она и выбирает наиболее удобный для себя вариант. Цель нашей работы – не в том, чтобы навязать программистам свои подходы, а в том, чтобы дать максимум информации о возможных рисках и предложить подходящие продукту улучшения и действия.
Что удалось сделать нашему отделу тестирования за прошедший год:
Изменения всегда сложны, но они необходимы, если мы болеем за наши продукты. И именно тестировщики могут внести значительный вклад в обеспечение качества продуктов.
В следующих материалах я с коллегами расскажу, как мы тестируем конкретные продукты, о выборе стратегии тестирования, об инструментах (например, Allure Enterprise edition – удобное средство для управления тестированием, формирования отчетности и даже управления автотестами), о том, как внедряем автоматические тесты в пайплайн и какие варианты развития видим (Test Driven Development, если вы подумали о нем, это только один из возможных вариантов ).
Выработка правил через тестирование
Команды, работающие по agile-методологии, часто пренебрегают качеством. Отчасти это происходит из-за того, что традиционные методологии тестирования не вписываются в «гибкий» контекст, отчасти из-за приоритетов скорости над качеством. Первоочередная задача agile-команды — оперативно реализовывать функции, которые нужны бизнес-заказчику. Это особенно актуально на стадии становления продукта, когда его функционал определяется буквально путем проб и ошибок, и разработчикам нужно быстро перестраивать продукт под текущие запросы. В такой ситуации команда часто решает так: позовем тестировщика потом, когда сделаем MVP/первую рабочую версию/познаем дзен — потому что просто не понимает, как организовать гибкое тестирование. В итоге часто получаются срывы сроков поставки, ошибки на демо и, самое страшное, в ПРОМ-среде.
В нашем случае была очень похожая ситуация: Управление разработки продуктов больших данных X5 Retail Group существует уже 2 года, и на первых порах качество продуктов поддерживалось только силами самих разработчиков — не было выделенной роли QA-специалиста, а отдел тестирования и первый тестировщик в продукте появились только год назад, когда продукты уже успели стартовать.
Сегодня в отделе тестирования уже 15 человек: 11 тестировщиков сопровождают продукты в командах, два человека развивают направление нагрузочного тестирования и еще два – направление автоматизации тестирования. Во многих продуктовых командах тестировщики стали катализатором важных изменений: их приход упорядочил процесс разработки и повысил стабильность релизов. Для этого мы подключали тестировщиков к уже работающим командам по следующей схеме:
1. Погружаемся в процесс
На первом этапе нам надо понять, как сейчас работает команда, как в ней распределяются роли и как происходит обмен информацией. Тестировщик начинает помогать с тестированием, больше в виде «контроля качества», попутно оценивая зрелость команды и процессов в команде – для этого есть своя небольшая «тепловая карта» зрелости, пример которой можно увидеть ниже. На ней можно видеть, насколько развиты различные направления (разработка, тестирование, DG, DevOps, поддержка) в каждом из наших продуктов.
Тепловая карта оценки зрелости
Оценку зрелости процессов тестировщики собирают вместе с разработчиками, оценивая набор технологических и методических практик, используемых командой. В итоге по тепловой карте мы можем увидеть, что и на каком участке можно улучшить – например развить практику Unit-тестов в разработке или автоматизировать проверки API в тестировании – для каждой стадии жизни продукта (прототип, пилот, пром) рекомендуется свой набор практик.
2. Вырабатываем рекомендации по улучшению
Разобравшись, как живет команда, можно продумать первые рекомендации по улучшению ее работы. Тут мы придерживаемся следующей логики: тестировщики – не выделенная функция, отвечающая за определенный участок, мы часть команды и можем влиять на весь процесс. Для того, чтобы облегчить запуск улучшений, начинаем с базовых вещей:
- Формируем общий словарь. Чтобы избежать разночтений, фиксируем все термины: что такое тесты, задачи, баги, как работать с дефектами и т.д. Не все знают, что дефект после исправления нужно отдать на проверку автору, а не просто закрыть! А потом еще и в релизы включить ;)
- Вырабатываем подход к оформлению задач (например, user stories) с критериями их приемки. Это нужно для того, чтобы однозначно понимать, что нужно реализовать и что бизнес будет смотреть в задаче, соответственно, что нужно проверять перед отправкой заказчику. Формулировка задачи в стиле «Сделать отчет» такого понимания не даст: из неё не понятно, хотим ли мы получить форму с выбором параметров или просто присылаемый на почту pdf по жестко заданным критериям? Представьте, какое поле для фантазии создают подобные формулировки и как сложно сдать задачу с такими размытыми критериями приемки!
- Обсуждаем Definition of Ready (критерии готовности задачи ко взятию в работу) и Definition of Done (критерии завершенности задачи) для задач разных типов.
- Фиксируем этапы спринта и один из критичных пунктов – точку «code freeze».
Это мы заглянули в этапы до тестирования и немного в само тестирование, а есть еще техническая часть с ведением тестовых стендов и работой с тестовыми данными и промышленная с сопровождением продукта. Тестировщики так или иначе задействованы на всех этих этапах – мы стараемся растить T-Shape специалистов, которые видят весь процесс производства, а не только свою непосредственную функцию.
3. Презентуем наши улучшения руководителям команд и заинтересованным лицам, делая акцент на том, какие проблемы решат эти улучшения
Процесс пойдёт проще, если заручиться поддержкой команды. Важно «продать» свою идею, показать, какой профит принесут предложенные вами изменения. Например, критерии приемки, которые мы упоминали выше, могут выглядеть как дополнительная работа для аналитика, но когда команда понимает, какую экономию времени она получит – а это от часов до дней, которые могут уходить на уточнение задачи, – то принимает улучшение намного легче.
В некоторых случаях можно действовать через владельца продукта. Например, продукту не хватает мониторинга (допустим, технического, с логами и красивыми графиками) и на настройку нет времени, ведь это не продуктовая задача. В таком случае можно обратиться к продакту и пояснить, какие именно выгоды он получит от мониторинга (стабильнее сразу не станет, но вырастет скорость локализации проблем), и попросить его выделить на это ресурсы.
Параллельно со стандартизацией работы в продуктовых командах идёт проработка подходов к тестированию, которые обеспечивают качество продуктов, например, оценка и подготовка необходимых объемов тестовых данных, проработка тестовой модели, формирование точек будущей автоматизации и т.д.
Всегда есть вероятность, что команда не примет предлагаемые изменения, какими бы разумными они вам ни казались. В каждом отдельном случае необходимо формировать свои подходы и искать индивидуальный способ убеждения. Продукты очень разные, и подходы, работающие в одном продукте, совсем не работают в другом.
Многие команды уверены, что способны сами организовать свою работу, и иногда это действительно так. Были случаи, когда наше участие сводилось к рекомендации основных точек проверки, и дальше команда прекрасно все реализовывала на уровне кода, а мы просто оставались рядом, всегда готовые помочь. Но чаще происходит по-другому: в команду приходит наш сотрудник, и разработчики в шутку начинают «плакать» от найденных тестировщиком дефектов, радуясь при этом, что дефекты найдены до демо или промышленного релиза.
Что изменилось
Перемены в продуктовых командах шли по-разному и затронули разные стороны процесса. В одной из команд тестирование сначала стало узким местом: оно требовало времени, и не все понимали, что же происходит на этом этапе. В виде эксперимента мы подключили разработчиков к запуску тестов, в результате чего они смогли прочувствовать работу тестировщиков и даже увидеть продукт в целом – не отдельную функцию построения отчета, например, а весь путь от авторизации пользователя в продукте и проведения бизнес-операций до итога – выгрузки отчета. Так мы усилили вовлеченность всей команды, сделали прозрачным процесс тестирования и показали важность этого действия, а описанная выше практика стала регулярной.
В другом продукте с нашей помощью изменился релизный цикл. Изначально было устроено так, что результаты спринта уходили в тестирование в пятницу после обеда, а в понедельник продукт уже попадал к заказчику. На тестирование и исправление критических ошибок оставался самый конец пятницы и лишь начало понедельника, и в итоге новая версия нередко выходила «сырой» или же разработчикам приходилось срочно фиксить баги в выходные. После пары сложных сдвигов поставки команда все же перенесла сдачу спринта на среду (не уменьшила длину спринта, а просто сдвинула график на два дня). Теперь у команды есть время проверить и исправить поставку в спокойной обстановке.
Окончательное решение, меняться или нет, остается за командой: именно она отвечает за продукт и его выход, поэтому она и выбирает наиболее удобный для себя вариант. Цель нашей работы – не в том, чтобы навязать программистам свои подходы, а в том, чтобы дать максимум информации о возможных рисках и предложить подходящие продукту улучшения и действия.
Что удалось сделать нашему отделу тестирования за прошедший год:
- В 7 продуктах отдела больших данных X5 Retail Group появилось регулярное функциональное тестирование, 2 из них вышли на стабильные релизы в ПРОМ без критичных замечаний. Организовано регулярное нагрузочное тестирование 3 продуктов.
- Команда тестирования выросла в 15 раз – с 1 до 15 человек :-) Начали формировать направления автоматизации и нагрузочного тестирования и находимся в поиске талантов!
В планах – работать с методологией тестирования (в частности, с подходами к тестированию в Agile), активно развивать автоматизацию, довести до ума инструментарий, обеспечить интеграцию инструментов, более детально заняться инфраструктурой для тестирования и тестовыми данными, а в идеале – прикоснуться и к работе с обучаемыми моделями.
Изменения всегда сложны, но они необходимы, если мы болеем за наши продукты. И именно тестировщики могут внести значительный вклад в обеспечение качества продуктов.
В следующих материалах я с коллегами расскажу, как мы тестируем конкретные продукты, о выборе стратегии тестирования, об инструментах (например, Allure Enterprise edition – удобное средство для управления тестированием, формирования отчетности и даже управления автотестами), о том, как внедряем автоматические тесты в пайплайн и какие варианты развития видим (Test Driven Development, если вы подумали о нем, это только один из возможных вариантов ).
Iksanova
Добрый день, Денис. Спасибо за интересную статью. Возник вопрос, практикуется ли автоматизация тестирования силами разработчиков и если да, то насколько успешно? Всё-таки, написание юнит-тестов для разработчиков привычная практика.