Путь к лучшему гибкому тестированию

Ежегодный мировой отчет о качестве, подготовленный Capgemini, показывает, что 42 % респондентов называют «недостаток профессионального опыта тестирования» проблемой при применении тестирования к Agile-разработке. Хотя появление Agile привело к увеличению скорости итераций разработки программного обеспечения, в некоторых случаях это произошло за счет снижения качества.

Жесткая конкуренция вынуждает команды постоянно выпускать новые обновления продуктов, но иногда это приводит к собственным издержкам, включая снижение внимания к тестированию. Некоторые, как Роб Мейсон, идут еще дальше и утверждают, что Agile убивает тестирование программного обеспечения. Недавно Facebook изменил свой девиз с «Двигайся быстро и ломай вещи» на «Двигайся быстро со стабильной инфраструктурой», пытаясь избавиться от искушения пожертвовать качеством.

Итак, как лучше интегрировать тестирование в новый мир гибкой разработки программного обеспечения? Гибкое тестирование.

Традиционное тестирование довольно громоздко и зависит от большого количества документации. Гибкое тестирование — это подход к процессу тестирования, который имитирует принципы гибкой разработки программного обеспечения, согласно которым:

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

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

Формализовать процесс цикла тестирования выпуска

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

Многие команды делают только одну сборку после каждого спринта, что не идеально для Agile-проектов. Переход к выпускам раз в неделю может быть полезным, постепенно переходя на несколько сборок в неделю. В идеале сборка для разработки и тестирование должны происходить ежедневно, а это означает, что разработчики помещают код в репозиторий каждый день, а запуск сборки запланирован на определенное время. Чтобы сделать еще один шаг вперед, разработчики смогут развертывать новый код по требованию. Для реализации этого команды могут использовать процесс непрерывной интеграции и непрерывного развертывания (CI/CD). CI/CD ограничивает возможность неудачной сборки в день основного выпуска.

При объединении CI/CD и автоматизации тестирования возможно раннее обнаружение критических ошибок, что дает разработчикам достаточно времени для исправления критических ошибок до запланированного выпуска клиента. Один из принципов Agile гласит, что работающее программное обеспечение является основным мерилом прогресса. В этом контексте формализованный цикл выпуска делает процесс тестирования более гибким.

Расширение возможностей тестировщиков с помощью инструментов развертывания

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

Например, в одной из моих команд мы использовали Git для контроля версий и Slack для связи. Разработчики создали Slackbot с доступом к Git, сценариям развертывания и одной виртуальной машине. Тестировщики смогли пропинговать бота с именем ветки, полученным из GitHub или Jira, и развернуть его в промежуточной среде.

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

Экспериментируйте с TDD и ATDD

Разработка через тестирование (TDD) — это тип процесса разработки программного обеспечения, в котором большое внимание уделяется качеству. Традиционно разработчик пишет код, а затем кто-то его тестирует и сообщает о найденных ошибках. В TDD разработчики сначала пишут модульные тесты, прежде чем даже написать какой-либо код, который завершит пользовательскую историю. Первоначально тесты терпят неудачу, пока разработчик не напишет минимальный объем кода для прохождения тестов. После этого код подвергается рефакторингу, чтобы соответствовать требованиям качества команды.

Разработка через приемочное тестирование (ATDD) следует той же логике, что и TDD, но, как следует из названия, фокусируется на приемочных тестах. В этом случае приемочные тесты создаются до разработки в сотрудничестве с разработчиками, тестировщиками и заказчиком (клиентом, владельцем продукта, бизнес-аналитиком и т. д.). Эти тесты помогают всем в команде понять требования клиента до того, как будет написан какой-либо код.

Такие методы, как TDD и ATDD, делают тестирование более гибким, перенося процедуры тестирования на ранние этапы жизненного цикла разработки. При написании тестовых сценариев на раннем этапе разработчики должны очень хорошо понимать требования. Это сводит к минимуму ненужное создание кода, а также устраняет любые неопределенности продукта в начале цикла разработки. Когда вопросы по продукту или конфликты возникают только на более поздних стадиях, время и затраты на разработку увеличиваются.

Обнаружение неэффективности путем отслеживания перемещения карточек задач

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

Иногда разработчики спешат со своей работой, пытаясь как можно быстрее выпустить функции и передать качество тестировщикам на аутсорсинг. Такая установка только перемещает узкое место дальше по спринту. Обеспечение качества (QA) — это самая важная система безопасности, которая есть у команды, но это может означать, что наличие QA дает разработчикам возможность отказаться от соображений качества.

Многие современные инструменты управления проектами имеют возможность отслеживать перемещение карточек задач на доске Scrum или Kanban. В нашем случае мы использовали Jira для анализа того, что произошло с задачами рассматриваемого разработчика, и провели сравнение с другими разработчиками в команде. Мы выяснили, что:

• Его задачи почти в два раза дольше находились в колонке тестирования на нашей доске;
• Его задачи гораздо чаще возвращались из QA для второго или третьего раунда исправления.

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

Чтобы решить эту проблему, мы начали с честного обсуждения с этим разработчиком. В нашем случае он просто не осознавал, насколько вреден его режим работы. Именно так он привык работать в своей предыдущей компании, где были более низкие требования к качеству и больший пул тестировщиков. После нашего разговора и с помощью нескольких сеансов парного программирования с нашим скрам-мастером он постепенно перешел на более качественный подход к разработке. Благодаря своим способностям к быстрому кодированию, он по-прежнему был высокоэффективен, но устранение «отходов» процесса контроля качества сделало весь процесс тестирования гораздо более гибким.

Добавьте автоматизацию тестирования в набор навыков команды QA

Тестирование в негибких проектах включает в себя такие действия, как анализ тестов, разработка тестов и выполнение тестов. Эти действия являются последовательными и требуют обширной документации. Когда компания переходит на Agile, чаще всего переход фокусируется в основном на разработчиков, а не на тестировщиков. Они перестают создавать обширную документацию (столп традиционного тестирования), но продолжают проводить ручное тестирование. Однако ручное тестирование выполняется медленно и, как правило, не справляется с быстрыми петлями обратной связи Agile.

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

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

Управление приоритетами тестирования

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

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

Поддержка клиентов

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

Управление продуктом

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

Автоматизация тестирования

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

Резюме: Качественное Agile-тестирование

Сделать тестирование более гибким — неизбежность, с которой сейчас сталкиваются многие команды разработчиков программного обеспечения. Тем не менее, качество не должно ставиться под угрозу из-за подхода «тестируйте как можно быстрее». Крайне важно, чтобы Agile-переход включал в себя переход к Agile-тестированию, и есть несколько способов добиться этого:

• Формализуйте процесс цикла тестирования выпуска.
• Расширьте возможности тестировщиков с помощью инструментов развертывания.
• Экспериментируйте с разработкой через тестирование и разработкой через приемочное тестирование.
• Выявляйте неэффективность, отслеживая движение карточек задач.
• Добавьте автоматизацию тестирования в набор навыков группы контроля качества.
• Управляйте приоритетами тестировщиков.

С каждым годом программное обеспечение становится лучше, а ожидания пользователей растут. Более того, по мере того как клиенты привыкают к высококачественным продуктам ведущих производителей программного обеспечения, таких как Google, Apple и Facebook, эти ожидания переносятся и на другие программные продукты. Таким образом, акцент на качество, вероятно, станет еще более важным в ближайшие годы. Эти улучшения тестирования и общего процесса разработки могут сделать тестирование более гибким и обеспечить высокий уровень качества продукта.