Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).
Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.
Я работаю в команде Integration, задача которой — интеграция нашего сервиса во внешние продукты и интеграция внешних продуктов в наш сервис. Например, мы интегрировали таск-трекер Jira. Jira Cards — визуальное отображение задач, с которыми можно удобно работать на доске, не заходя в Jira.
Началось всё с банальной проблемы. Когда кто-то из тестировщиков уходил на больничный — производительность команды сильно снижалась. Команда продолжала работать над задачами, но код доходил до этапа тестирования и задача вставала на паузу. В результате новый функционал не попадал на production вовремя.
Уход тестировщика в отпуск — отдельная история. Ему нужно заранее найти кого-то из тестеров, кто готов взять его задачи в дополнение к своим, договориться, погрузить в задачи. Одновременно уйти в отпуск двум тестерам — непозволительная роскошь.
Мы стали думать, как можно решить проблему, и поняли, что настоящая проблема в том, что узкое горлышко процессов разработки — тестирование. Покажу на примере нескольких историй.
Есть я и разработчик. У каждого свои задачи. Разработчик закончил одну из задач и отдал её мне на тестирование. Так как у этой задачи приоритет выше, чем у моих текущих, — я переключаюсь на неё. Нахожу баги, завожу всё в Jira и отдаю обратно разработчику на доработку.
Возвращаюсь к задачам, которые пришлось отложить. Разработчик переключается с новых задач на задачу, которую я вернул. Правит баги и возвращает мне на тестирование. Я снова нахожу баги и снова возвращаю задачу. Этот процесс может продолжаться очень долго.
В итоге, общее время работы над задачей увеличивается в несколько раз, вслед за этим увеличивается Time to market, а это критично для нас как для продуктовой компании. Причин увеличения времени работы над задачей несколько:
В нашей scrum-команде несколько разработчиков. Они регулярно передают свои задачи мне на тестирование. Образуется очередь задач, за которые я берусь, исходя из приоритетов.
Так мы работали около года, однако за это время компания сильно выросла: увеличилось количество проектов и разработчиков, а значит и количество задач в тестировании. При этом в нашей команде я был по-прежнему единственным тестировщиком и не мог кратно увеличить свою скорость. В итоге, в очереди на тестирование накапливалось всё больше задач, а процесс перекидывания задач между разработчиком и тестировщиком увеличивал время ожидания.
Внезапно я заболел. Доставка новых фич от нашей команды на production полностью остановилась. Что делать команде в такой ситуации? Можно попросить помощи у тестировщика из другой команды. Но, с большой долей вероятности, он не будет погружен в нашу специфику, что негативно скажется на качестве и сроках в обеих командах.
Вывод из обеих историй одинаковый — команды слишком сильно зависят от тестировщика:
Самая очевидная мысль — увеличить штат тестировщиков. Это будет работать, но только до определённого момента: количество задач будет постоянно расти, а бесконечно увеличивать количество тестировщиков невозможно — в какой-то момент это станет дорого и неэффективно. На тему проблем “ресурсного мышления” (не можете решить проблему? Наймите ещё одного сотрудника) хорошо написал Фёдор Овчинников, CEO Dodo Pizza.
Гораздо эффективнее сохранить скорость и качество разработки в рамках текущих ресурсов. Поэтому мы решили запустить эксперимент, который поможет командам создавать функционал сразу с учётом всех рисков и пограничных ситуаций. Назвали его Transform tester to QA, потому что он про трансформацию одной из ролей в команде: от monkey-тестировщика, выявляющего ошибки за разработчиком, к QA-инженеру, осознанно обеспечивающему качество на всех этапах процесса разработки.
Цели эксперимента:
Первым шагом важно было изменить мышление команды. Все привыкли, что за качество в команде отвечает тестировщик.
Наша гипотеза была в том, что увеличение времени на подготовку и проверку задач поможет уменьшить количество итераций в работе над одной задачей. Это, в свою очередь, позволит выводить новый функционал на production без потери скорости и уровня качества, а может быть быстрее и с лучшим качеством.
Вместе с командой и с тестировщиками из других команд мы разработали новую схему работы. За полгода, как команда работает по ней, мы учли сложности и проблемы, возникшие по пути, и сегодня она выглядит так:
Product Owner презентует постановку задачи перед командой. Команда анализирует постановку, чтобы выявить пограничные ситуации с технической и продуктовой сторон. Если возникают вопросы, которые необходимо дополнительно исследовать — ставится отдельная задача, на которую выделяется время в спринте.
Итогом анализа постановки задачи является техническое решение, которое составляют один или несколько разработчиков. С техническим решением должны быть ознакомлены и согласны все релевантные сотрудники компании, в том числе QA. В техническом решении описывается проблема, которую мы решаем, функциональные блоки продукта, которые будут задеты, и предполагаемый план внесения изменений в код.
Такое решение позволяет выявить более простое, более качественное решение, основываясь на опыте релевантных участников процесса разработки. Имея на руках подробное техническое описание — легче увидеть и избежать блокирующих проблем, проще проводить код-ревью.
Вот пример некоторых блоков из технического решения:
Параллельно с этим разработчик или QA составляют тестовый сценарий, в котором учитываются все возможные места возникновения проблем. Если это делает разработчик, он обязательно отдаёт сценарий на проверку QA, который проверяет его на полноту и достаточность. Если сценарий составляет QA — разработчик должен подтвердить, что понимает, как можно выполнить каждый из его пунктов. Команда также оценивает сценарий на корректность.
Для составления и хранения сценариев мы используем HipTest.
Разработчик приступает к написанию кода, исходя из технического решения и учитывая все возможные ситуации, описанные в тестовой документации. Проходит код-ревью и проверяет код по тестовым сценариям. Производит мерж в мастер.
На данном этапе QA оказывает необходимую поддержку разработчику. Например, помогает с воспроизведением сложных кейсов, настройкой тестового окружения, проведением нагрузочного тестирования, подсказывает по возможным нюансам вывода больших фичей на production.
Это финальный этап. Здесь от команды могут потребоваться пред\пост-релизные действия, например, включение нового функционала для бета-пользователей.
Новая схема работы потребовала от разработчиков большего погружения в процесс тестирования. Поэтому мне как QA было важно обеспечить их всем необходимым инструментарием и научить основам тестирования функционала. Вместе с QA из других команд мы составили список необходимой документации, создали недостающие инструкции по тестированию и доработали существующие с учётом неочевидных для разработчиков вещей.
Затем мы выдали разработчикам доступ ко всем инструментам тестирования и тестовым средам и начали совместно проводить тестирование. По началу разработчикам не хотелось брать на себя ответственность за результаты тестирования, потому что за ними больше никто ничего не проверял, это было для них непривычно. У каждого разработчика были только тестовый сценарий, разработанный им функционал и кнопка Merge. Но постепенно они привыкли.
Со старта эксперимента прошло полгода. На графике отображена статистика количества багов по неделям в нашей команде. Красным цветом отображается количество всех найденных командой багов, зелёным — количество исправленных.
Видно, что уровень красной линии сохранился на том же уровне, кроме всплеска в начале эксперимента. Багов не стало больше, а значит текущий уровень качества мы сохранили.
При этом среднее время работы над задачами уменьшилось всего на 2%: до старта эксперимента оно составляло 12 часов 40 минут, после — 12 часов 25 минут. Значит мы смогли сохранить текущую скорость работы над задачами.
В итоге, в нашей команде теперь нет жёсткой зависимости от QA. Если я заболею или уйду в отпуск — команда продолжит работу без потери в скорости и качестве.
Считаем ли мы эксперимент успешным, несмотря на то, что показатели времени и качества остались прежними? Да, считаем, потому что мы сохранили скорость и качество работы и высвободили время QA для более осознанной работы над качеством продукта и процессов разработки. Например, для проведения исследовательского тестирования, увеличения покрытия функционала тестами и описания принципов и правил разработки тестовой документации во всех командах.
В других командах мы посеяли зерно эксперимента. Например, в одной из команд QA теперь не тестирует то, что описано разработчиком в пулл-реквесте, потому что разработчик может посмотреть это самостоятельно. В другой команде QA анализирует изменения реквеста и проверяет только сложные и неочевидные кейсы.
Это сложный и долгий эксперимент. Он не внедряется по щелчку пальцев, к нему нужно кропотливо готовиться и не ждать быстрых результатов.
Будьте готовы к негативу со стороны команды. Нельзя просто взять и сказать, что теперь проверкой функционала занимаются разработчики. Необходимо подготовить их к этому, выработать подходы, объяснить ценность эксперимента для команды и продукта.
Потеря скорости на старте неизбежна. Время на обучение разработчиков, написание недостающей документации и перестройка процессов занимает время, которым придётся пожертвовать в пользу эксперимента.
Готового решения нет. Подобные процессы внедряются, например, в Atlassian, но это не значит, что у вас получится также внедрить их у себя as is. Важна адаптация под культуру компании и специфику команд.
Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.
Я работаю в команде Integration, задача которой — интеграция нашего сервиса во внешние продукты и интеграция внешних продуктов в наш сервис. Например, мы интегрировали таск-трекер Jira. Jira Cards — визуальное отображение задач, с которыми можно удобно работать на доске, не заходя в Jira.
С чего начался эксперимент
Началось всё с банальной проблемы. Когда кто-то из тестировщиков уходил на больничный — производительность команды сильно снижалась. Команда продолжала работать над задачами, но код доходил до этапа тестирования и задача вставала на паузу. В результате новый функционал не попадал на production вовремя.
Уход тестировщика в отпуск — отдельная история. Ему нужно заранее найти кого-то из тестеров, кто готов взять его задачи в дополнение к своим, договориться, погрузить в задачи. Одновременно уйти в отпуск двум тестерам — непозволительная роскошь.
Мы стали думать, как можно решить проблему, и поняли, что настоящая проблема в том, что узкое горлышко процессов разработки — тестирование. Покажу на примере нескольких историй.
История первая: бесконечное перекидывание задачи
Есть я и разработчик. У каждого свои задачи. Разработчик закончил одну из задач и отдал её мне на тестирование. Так как у этой задачи приоритет выше, чем у моих текущих, — я переключаюсь на неё. Нахожу баги, завожу всё в Jira и отдаю обратно разработчику на доработку.
Возвращаюсь к задачам, которые пришлось отложить. Разработчик переключается с новых задач на задачу, которую я вернул. Правит баги и возвращает мне на тестирование. Я снова нахожу баги и снова возвращаю задачу. Этот процесс может продолжаться очень долго.
В итоге, общее время работы над задачей увеличивается в несколько раз, вслед за этим увеличивается Time to market, а это критично для нас как для продуктовой компании. Причин увеличения времени работы над задачей несколько:
- Задача постоянно перекидывается между разработкой и тестированием.
- Задача простаивает в ожидании тестировщика или разработчика.
- Разработчику и тестировщику приходиться регулярно переключаться между задачами, что требует дополнительного времени и энергии.
История вторая: растущая очередь задач
В нашей scrum-команде несколько разработчиков. Они регулярно передают свои задачи мне на тестирование. Образуется очередь задач, за которые я берусь, исходя из приоритетов.
Так мы работали около года, однако за это время компания сильно выросла: увеличилось количество проектов и разработчиков, а значит и количество задач в тестировании. При этом в нашей команде я был по-прежнему единственным тестировщиком и не мог кратно увеличить свою скорость. В итоге, в очереди на тестирование накапливалось всё больше задач, а процесс перекидывания задач между разработчиком и тестировщиком увеличивал время ожидания.
Внезапно я заболел. Доставка новых фич от нашей команды на production полностью остановилась. Что делать команде в такой ситуации? Можно попросить помощи у тестировщика из другой команды. Но, с большой долей вероятности, он не будет погружен в нашу специфику, что негативно скажется на качестве и сроках в обеих командах.
Вывод из обеих историй одинаковый — команды слишком сильно зависят от тестировщика:
- Производительность всей команды ограничена производительностью тестировщика.
- Количество разработчиков не может быть увеличено без увеличения штата тестировщиков.
- Увеличение скорости разработки не имеет смысла, если все задачи попадают в очередь на тестирование.
- Пока работу разработчика проверяет тестировщик — чувство ответственности за качество у разработчика снижается.
- Если тестировщика нет, то процесс вывода нового функционала страдает.
Давайте увеличим штат тестировщиков?
Самая очевидная мысль — увеличить штат тестировщиков. Это будет работать, но только до определённого момента: количество задач будет постоянно расти, а бесконечно увеличивать количество тестировщиков невозможно — в какой-то момент это станет дорого и неэффективно. На тему проблем “ресурсного мышления” (не можете решить проблему? Наймите ещё одного сотрудника) хорошо написал Фёдор Овчинников, CEO Dodo Pizza.
Гораздо эффективнее сохранить скорость и качество разработки в рамках текущих ресурсов. Поэтому мы решили запустить эксперимент, который поможет командам создавать функционал сразу с учётом всех рисков и пограничных ситуаций. Назвали его Transform tester to QA, потому что он про трансформацию одной из ролей в команде: от monkey-тестировщика, выявляющего ошибки за разработчиком, к QA-инженеру, осознанно обеспечивающему качество на всех этапах процесса разработки.
Давайте улучшим процессы в разработке
Цели эксперимента:
- Снять зависимость команды от тестировщиков, но без потери качества и сроков.
- Повысить уровень обеспечения качества QA-инженерами в командах.
Первым шагом важно было изменить мышление команды. Все привыкли, что за качество в команде отвечает тестировщик.
Наша гипотеза была в том, что увеличение времени на подготовку и проверку задач поможет уменьшить количество итераций в работе над одной задачей. Это, в свою очередь, позволит выводить новый функционал на production без потери скорости и уровня качества, а может быть быстрее и с лучшим качеством.
Вместе с командой и с тестировщиками из других команд мы разработали новую схему работы. За полгода, как команда работает по ней, мы учли сложности и проблемы, возникшие по пути, и сегодня она выглядит так:
- Презентация постановки.
- Техническое решение и тестовый сценарий.
- Разработка и проверка.
- Релиз.
Постановка задачи
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. Важна адаптация под культуру компании и специфику команд.
Комментарии (3)
orcy
26.04.2019 21:401. Когда тестировщик это выделенный человек, получается что кто-то еще смотрит на фичу перед релизом, причем свежим взглядом и возможно немного в других условиях. Это позволяет получить некоторый фидбэк (например, «то как это работает выглядит очень понятно», «здесь опечатка», «на моем компьютере не работает»). Не боитесь ли вы что потеряете такого рода обратную связь?
2. Как разработчики относятся к тому что им нужно готовить какие-то тест-кейсы и проводить тесты? Как справляются, это же немного другой способ мышления и навыков.
Спасибо за статью, тема мне кажется очень интересной.
gigimon
Если я правильно понял, то вы просто заставляете разработчиков перед отдачей тикета в тестинг, пройтись самостоятельно по тест плану, который написал он сам, вместе с QA?
У вас на графике, после начала эксперимента, стало больше фикситься багов, это появилось время на старые из бэклога или?
yanov Автор
1) Мы никого не заставляем. Обсуждаем и доносим, что таким образом команда снимает внутренние зависимости. Отдельной стадии тестинга теперь нет. Разработчик самостоятельно производит проверку по тестовым сценариям, дальше — продакшен. Я подключаюсь в тех моментах, когда требуется помощь с тестовым окружением, с воспроизведением сложных кейсов, при взаимодействии с другими командами и прочее.
2) Это связано с процессами внутри команды. Мы стали более внимательно относиться к багам, соблюдать внутренний OLA по багам (Operational Level Agreement), ежедневно к дейлику проверяем все возможные каналы поступления багов. И да, разобрались со старыми багами из бэклога.