Как в Додо Пицце реорганизовали систему тестирования через Kaiten
Рассказываем про то, как построить децентрализованный QA с помощью Kaiten
Меня зовут Евгений Иванченко, и я возглавляю Web QA Гильдию в Dodo Engineering. В нашей компании произошли интересные изменения: мы полностью трансформировали подход к тестированию, отказавшись от централизованного QA-отдела. Это может показаться радикальным решением, но результаты говорят сами за себя.
Мы не прекратили заниматься контролем качества, а просто изменили организационную структуру. Давайте разберем, как мы осуществили эту трансформацию и какую роль в ней сыграла система Kaiten.
От монолитного QA к распределенной системе
Начнем с причин таких перемен. Тщательно изучив рабочие процессы, мы обнаружили, что основной проблемой стала коммуникация между командами разработки и тестирования.
В сфере разработки ПО тестирование неразрывно связано с написанием кода. Новую функцию нельзя считать готовой, пока она не прошла все необходимые проверки. Следовательно, любые задержки между разработкой и тестированием существенно увеличивают время реализации задачи. Чем сложнее коммуникация между разработчиком и тестировщиком, тем дольше путь от идеи до релиза.
В идеальном сценарии каждый программист мог бы самостоятельно тестировать свой код, но реальность сложнее: не все обладают необходимыми навыками для проведения комплексного тестирования, особенно когда речь идет об интеграционных тестах и других специфических проверках. При этом практика показывает, что эффективность значительно возрастает, когда тестировщик работает в непосредственной близости с разработчиком. Вдохновившись концепцией распределенного интеллекта осьминога, где каждое щупальце обладает определенной автономией, мы решили применить похожий подход.
В новой модели базовые автотесты создаются самими разработчиками. При необходимости более сложного тестирования они обращаются к QA-специалисту, который является частью их команды. Это существенно сократило время на коммуникацию и согласование.
Однако это не означает изоляцию тестировщиков. Мы создали QA-гильдию — небольшое сообщество внутри компании, которое служит мозговым центром тестирования.
Теперь подробно рассмотрим, как мы организовали QA-процессы с помощью Kaiten.
От теории к практике: организация рабочих процессов
Как же выстроена работа внутри продуктовой команды? В системе Kaiten каждая команда располагает собственным рабочим пространством, где происходит весь жизненный цикл задач от создания до завершения.
Первая остановка для любой задачи — доска Inbox. Это своеобразный накопитель для всех задач, требующих внимания, но не подлежащих мгновенному решению. Важно отметить, что сюда попадают не только задачи по разработке. Например, здесь может появиться задача по созданию обучающего видеоролика для демонстрации новой функциональности в пиццерии.
Процесс сортировки задач напоминает распределение студентов по факультетам в известной саге о юном волшебнике. На ежедневных стендапах команда рассматривает задачи из Inbox и принимает два ключевых решения:
- определение временных рамок: задача либо включается в текущий спринт, либо откладывается в общий бэклог для последующих итераций;
- для задач текущего спринта определяется их категория. Мы различаем технические задачи, исследовательские работы, бизнес-задачи, баг-репорты и общие вопросы. После этого определяется приоритетность: Expedite для срочных задач, Sprint Goal для задач, связанных с целями спринта, и Miscellaneous для остальных.
На спринт-борде разворачивается настоящее путешествие, знакомое всем, кто работает по гибким методологиям. Задачи последовательно проходят через несколько этапов. Начинается всё с колонки To Do, затем при взятии в работу карточка перемещается в In Progress. Готовый к развертыванию функционал отправляется в Deployment. Для проверок после выкатки существует отдельная колонка Post Production.
Примечательно отсутствие выделенной колонки для тестирования — это наше принципиальное решение, так как тестирование является неотъемлемой частью разработки. Задача считается выполненной только после проведения всех необходимых тестов.
Стандартные модульные тесты разработчики пишут самостоятельно. Однако в процессе работы, когда задача находится в статусе In Progress или Deployment, может появиться необходимость в более глубоком тестировании из-за повышенной сложности функционала. В таких случаях разработчик привлекает тестировщика из своей команды, используя систему тегов. Тестировщик оперативно подключается к процессу и формирует детальный отчет о найденных проблемах.
Kaiten предлагает не только удобную визуализацию рабочего процесса. Одним из важных преимуществ стала интеграция с GitHub: при указании номера задачи в комментарии к коммиту система автоматически создает ссылку на этот коммит в карточке задачи включая информацию об авторе изменений.
Гильдия QA: объединяя профессионалов
Переход к распределенной системе тестирования несет в себе определенные риски. Простое распределение тестировщиков по командам без дополнительной поддержки может привести к профессиональной изоляции. В худшем случае специалист может застрять в рутине и перестать развиваться, в лучшем — будет тратить время на создание решений, уже существующих в других командах. Именно поэтому мы создали Гильдию, которая объединяет тестировщиков по направлениям (например, Web QA отдельно от Mobile QA). Гильдия выступает центром компетенций, где происходит обмен опытом, совершенствование инструментария и методологий.
Организация работы Гильдии в Kaiten имеет свою специфику. Здесь также есть доска Inbox, но она упрощена до одной колонки. Основная рабочая доска содержит классический набор статусов: To Do, In Progress и Done.
Характерный пример работы Гильдии — внедрение инструмента для тестирования Allure TestOps. Подобные масштабные изменения требуют координации на уровне всей компании, так как их реализация силами одной команды была бы неэффективной. Централизованное внедрение позволяет достичь качественного скачка в работе всей организации.
Пример
Рассмотрим показательный случай, которому мы посвятили отдельное исследование, — внедрение системы документирования инцидентов (постмортемов). На первый взгляд кажется очевидным: когда происходит серьезный сбой в рабочей среде, недостаточно просто устранить неполадку, — необходимо провести тщательный анализ ситуации. Однако в суете решения проблемы часто не хватает времени на аналитику, а позже это просто откладывается в долгий ящик. Именно по этой причине была разработана и внедрена обязательная методология написания постмортемов — структурированная и подконтрольная процедура, появившаяся благодаря инициативе Гильдии и возможностям Kaiten.
Когда речь зашла об упразднении отдела тестирования, я допустил небольшую неточность. В определенных ситуациях Гильдия фактически берет на себя функции целого подразделения. Несмотря на то, что каждая команда занимается разработкой собственного микросервиса, в конечном итоге мы создаем единую систему — монолит. Комплексное тестирование такой системы невозможно поручить одной конкретной продуктовой команде, поэтому эта ответственность ложится на плечи Гильдии.
Поскольку монолит не закреплен за конкретной командой, возникает закономерный вопрос об ответственности за его выпуск. Мы нашли децентрализованное решение этой проблемы. По специально разработанной методике назначается «релизмен» — специалист, отвечающий за конкретный релиз. Хотя его обязанности не слишком сложны, для новичков они могут показаться запутанными. Именно поэтому Гильдия QA разработала специализированного бота-помощника. Это приложение автоматически создает в Kaiten карточку с детальным чек-листом для релизмена, формирует специальную колонку релиза на доске монолита, организует тематический чат в Slack, инициирует pull request в GitHub и выполняет другие автоматизируемые задачи. Подробности о функционале бота описаны в отдельной публикации.
Можно долго дискутировать о том, что имеет большее значение: инструментарий или методология? Этот вопрос напоминает извечную дилемму о курице и яйце. Процессы порождают потребность в инструментах, но без соответствующего инструментария невозможно наладить эффективный рабочий процесс.
Итог работы в Kaiten
Kaiten обладает множеством преимуществ: простота освоения, широкие возможности настройки под индивидуальные потребности, а в современных реалиях немаловажным фактором является и страна-разработчик.
Означает ли это, что мы нашли универсальное решение всех проблем? Конечно, нет. Но мы и не стремились к этому. Нам требовался надежный, практичный инструмент с удобным управлением. Мы его обнаружили и успешно использовали для построения новой системы рабочих процессов.
