Лучшие практики по стратегии тестирования для Scrum-команды

Скрам минус план тестирования равняется POC на стероидах.

В настоящее время большинство успешных проектов начинаются с Proof of Concept (POC), сравнительно небольшой оценки идеи, при которой выбранная технология и пакет функций сначала проверяются, оцениваются на предмет потенциального воздействия на бизнес-пользователей, а затем, после подтверждения достойных инвестиций, полноразмерная проектная группа занимается проектированием и поставкой полнофункционального продукта, а также развертыванием его в рабочей среде.

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

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

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

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

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

Распределить боль

С чего же еще нам начать, имея дело с ненужными заботами, как не с расщепления боли :).

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

№1. Разрабатывайте код модульного тестирования для каждого созданного фрагмента нового кода.

Если вам удастся убедить ваши scrum-команды добавить в пункт Definition Of Done разработку модульных тестов для каждого нового кода, созданного в рамках спринта, то в долгосрочной перспективе это будет большим достижением.

Причины достаточно очевидны:

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

• Такие модульные тесты можно подключать к автоматизированным конвейерам DevOps и выполнять при каждом отдельном развертывании в среде разработки или тестирования. Кроме того, метрики из пайплайна можно легко экспортировать, а затем использовать для демонстрации бизнес-пользователям процентного покрытия тестовых случаев, напрямую привязанных к исходному коду.

Самое главное начать очень скоро. Чем позже начнут разрабатываться модульные тесты, тем больше будет отвлекать разработчиков их добавление в течение спринта.

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

№ 2. Сделайте процедуру выполнения всех частей модульных тестов в среде разработки.

Даже до создания запроса на слияние нового кода с основной веткой должно быть стандартным действием тестирование как кода функции, так и кода модульного тестирования в среде разработки. При этом будет обеспечено, что:

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

№3. Ожидайте выполнение модульного теста после слияния кода с основной веткой

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

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

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

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

Теперь этот шаг можно пропустить в одном конкретном случае:

• Автоматизированные модульные тесты в пайплайнах DevOps настолько всеобъемлющи, что уже охватывают все ручное тестирование, выполняемое поверх него.

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

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

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

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

Подготовьтесь к функциональному тестированию

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

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

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

№1. Целевое функциональное тестирование новых историй спринта

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

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

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

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

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

Таким образом, разработчики потратят минимум времени на функциональное тестирование и смогут сконцентрироваться на том, что им нравится больше всего.

№ 2. Выполнение регрессионных тестов

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

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

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

В некоторых случаях регрессионные тесты даже неявно покрывают также новые функции в спринте, например, если новая история в спринте меняет какую-то конкретную часть существующего потока.

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

Настаивайте на выполнении тестов обеспечения качества перед каждым производственным выпуском

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

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

Тест QA должен выполняться исключительно людьми, не входящими в команду Scrum, в идеале самими бизнес-пользователями в специальной среде, максимально приближенной к будущей работе. В качестве альтернативы, владелец продукта может заменить здесь конечных пользователей.

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

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

Куда идти дальше отсюда?

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

Но, конечно же, вам не нужно останавливаться на достигнутом.

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

Переход на один уровень вверх также означает внедрение автоматических тестов.

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

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