Home

Оригинальная публикация

Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).

Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.

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

С чего начался эксперимент

Началось всё с банальной проблемы. Когда кто-то из тестировщиков уходил на больничный — производительность команды сильно снижалась. Команда продолжала работать над задачами, но код доходил до этапа тестирования и задача вставала на паузу. В результате новый функционал не попадал на production вовремя.

Уход тестировщика в отпуск — отдельная история. Ему нужно заранее найти кого-то из тестеров, кто готов взять его задачи в дополнение к своим, договориться, погрузить в задачи. Одновременно уйти в отпуск двум тестерам — непозволительная роскошь.

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

История первая: бесконечное перекидывание задачи

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

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



В итоге, общее время работы над задачей увеличивается в несколько раз, вслед за этим увеличивается Time to market, а это критично для нас как для продуктовой компании. Причин увеличения времени работы над задачей несколько:

1. Задача постоянно перекидывается между разработкой и тестированием.
2. Задача простаивает в ожидании тестировщика или разработчика.
3. Разработчику и тестировщику приходиться регулярно переключаться между задачами, что требует дополнительного времени и энергии.

История вторая: растущая очередь задач

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

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

Внезапно я заболел. Доставка новых фич от нашей команды на production полностью остановилась. Что делать команде в такой ситуации? Можно попросить помощи у тестировщика из другой команды. Но, с большой долей вероятности, он не будет погружен в нашу специфику, что негативно скажется на качестве и сроках в обеих командах.

Вывод из обеих историй одинаковый — команды слишком сильно зависят от тестировщика:

• Производительность всей команды ограничена производительностью тестировщика.
• Количество разработчиков не может быть увеличено без увеличения штата тестировщиков.
• Увеличение скорости разработки не имеет смысла, если все задачи попадают в очередь на тестирование.
• Пока работу разработчика проверяет тестировщик — чувство ответственности за качество у разработчика снижается.
• Если тестировщика нет, то процесс вывода нового функционала страдает.

Давайте увеличим штат тестировщиков?

Самая очевидная мысль — увеличить штат тестировщиков. Это будет работать, но только до определённого момента: количество задач будет постоянно расти, а бесконечно увеличивать количество тестировщиков невозможно — в какой-то момент это станет дорого и неэффективно. На тему проблем “ресурсного мышления” (не можете решить проблему? Наймите ещё одного сотрудника) хорошо написал Фёдор Овчинников, CEO Dodo Pizza.

Гораздо эффективнее сохранить скорость и качество разработки в рамках текущих ресурсов. Поэтому мы решили запустить эксперимент, который поможет командам создавать функционал сразу с учётом всех рисков и пограничных ситуаций. Назвали его Transform tester to QA, потому что он про трансформацию одной из ролей в команде: от monkey-тестировщика, выявляющего ошибки за разработчиком, к QA-инженеру, осознанно обеспечивающему качество на всех этапах процесса разработки.

Давайте улучшим процессы в разработке

Цели эксперимента:

• Снять зависимость команды от тестировщиков, но без потери качества и сроков.
• Повысить уровень обеспечения качества QA-инженерами в командах.

Первым шагом важно было изменить мышление команды. Все привыкли, что за качество в команде отвечает тестировщик.

Наша гипотеза была в том, что увеличение времени на подготовку и проверку задач поможет уменьшить количество итераций в работе над одной задачей. Это, в свою очередь, позволит выводить новый функционал на production без потери скорости и уровня качества, а может быть быстрее и с лучшим качеством.

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

1. Презентация постановки.
2. Техническое решение и тестовый сценарий.
3. Разработка и проверка.
4. Релиз.

Постановка задачи

Product Owner презентует постановку задачи перед командой. Команда анализирует постановку, чтобы выявить пограничные ситуации с технической и продуктовой сторон. Если возникают вопросы, которые необходимо дополнительно исследовать — ставится отдельная задача, на которую выделяется время в спринте.

Техническое решение

Итогом анализа постановки задачи является техническое решение, которое составляют один или несколько разработчиков. С техническим решением должны быть ознакомлены и согласны все релевантные сотрудники компании, в том числе QA. В техническом решении описывается проблема, которую мы решаем, функциональные блоки продукта, которые будут задеты, и предполагаемый план внесения изменений в код.

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

Вот пример некоторых блоков из технического решения:

Описание задачи

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

Меняется ли модель данных?

Для сервера речь идет об объектах и моделях.
Если модель данных сложная, можно представить её в виде UML-диаграммы, либо в виде текстового описания.

Изменяется ли взаимодействие между клиентом и сервером?

Описание изменений. Если это API, то можно ли его будет отдать внешним пользователям? Не забыть про обработку ошибок — т.е. указать правильные reason.

Тестовый сценарий

Параллельно с этим разработчик или QA составляют тестовый сценарий, в котором учитываются все возможные места возникновения проблем. Если это делает разработчик, он обязательно отдаёт сценарий на проверку QA, который проверяет его на полноту и достаточность. Если сценарий составляет QA — разработчик должен подтвердить, что понимает, как можно выполнить каждый из его пунктов. Команда также оценивает сценарий на корректность.

Для составления и хранения сценариев мы используем HipTest.

Разработка и проверка

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

На данном этапе QA оказывает необходимую поддержку разработчику. Например, помогает с воспроизведением сложных кейсов, настройкой тестового окружения, проведением нагрузочного тестирования, подсказывает по возможным нюансам вывода больших фичей на production.

Релиз готового функционала

Это финальный этап. Здесь от команды могут потребоваться пред\пост-релизные действия, например, включение нового функционала для бета-пользователей.

Документация и инструменты

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

Затем мы выдали разработчикам доступ ко всем инструментам тестирования и тестовым средам и начали совместно проводить тестирование. По началу разработчикам не хотелось брать на себя ответственность за результаты тестирования, потому что за ними больше никто ничего не проверял, это было для них непривычно. У каждого разработчика были только тестовый сценарий, разработанный им функционал и кнопка Merge. Но постепенно они привыкли.

Результаты эксперимента

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



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

При этом среднее время работы над задачами уменьшилось всего на 2%: до старта эксперимента оно составляло 12 часов 40 минут, после — 12 часов 25 минут. Значит мы смогли сохранить текущую скорость работы над задачами.

В итоге, в нашей команде теперь нет жёсткой зависимости от QA. Если я заболею или уйду в отпуск — команда продолжит работу без потери в скорости и качестве.

Считаем ли мы эксперимент успешным, несмотря на то, что показатели времени и качества остались прежними? Да, считаем, потому что мы сохранили скорость и качество работы и высвободили время QA для более осознанной работы над качеством продукта и процессов разработки. Например, для проведения исследовательского тестирования, увеличения покрытия функционала тестами и описания принципов и правил разработки тестовой документации во всех командах.

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

О чём стоит помнить перед началом эксперимента

Это сложный и долгий эксперимент. Он не внедряется по щелчку пальцев, к нему нужно кропотливо готовиться и не ждать быстрых результатов.

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

Потеря скорости на старте неизбежна. Время на обучение разработчиков, написание недостающей документации и перестройка процессов занимает время, которым придётся пожертвовать в пользу эксперимента.

Готового решения нет. Подобные процессы внедряются, например, в Atlassian, но это не значит, что у вас получится также внедрить их у себя as is. Важна адаптация под культуру компании и специфику команд.

Обсудить в форуме