Автор: Джош Грант (Josh Grant)
Оригинал статьи
Перевод: Ольга Алифанова

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

Разработка хорошей релизной тест-практики

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

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

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

Команды, стремящиеся к хорошим релизам, должны следовать трем этим советам:

• Имейте релизный план.
• Проинформируйте всех заинтересованных лиц.
• Следуйте хорошим релизным тест-практикам.

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

Имейте релизный план

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

В целом, релизный план может быть:

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

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

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

Важно получить одобрение заинтересованных лиц

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

Коллективно создали релизный план – что дальше?

Как уже упоминалось, релизный план может включать в себя любой процесс, но вот что должно быть в абсолютно любом плане релиза:

• Пошаговые инструкции по деплою и релизу приложения.
• Стратегии для отката назад или вперед, если что-то пошло не так.

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

Общий доступ к тест-планам

Идеи для общего доступа к планам релиза:

• Общий документ, создаваемый и обновляемый для каждого релиза. Один из членов релизной команды создает единый документ, доступный всем участникам релиза. Этот документ может содержать все шаги релизного плана, их даты и время, и указывать ответственное за каждый шаг лицо. Выкладка этого документа в облака упростит задачу обновления и просмотра плана в реальном времени. Релизный документ можно сохранять как справку или релизный артефакт.
• Общий канал в чате или комната для релиза. Если все в релизной команде имеют доступ к чат-приложениям вроде Skype или Slack, создание общего пространства для координации релиза хорошо сработает. Это особенно полезно, если кто-то из участников работает удаленно. Команда может вести переговоры в режиме реального времени и подтверждать, что каждый шаг релизного плана в процессе или завершен.
• Использование маркерной доски со стикерами для планирования релиза и оценки прогресса. Эффективное, низкотехнологичное решение для координации релиза – установить доску с маркерами и стикерами. Доску можно разделить на стадии релиза, и участники смогут перемещать стикеры и делать наброски по ходу релиза. Этот подход хорош возможностью быстрой визуальной оценки прогресса релиза.
• Некая комбинация всего вышеперечисленного. К примеру, у команды есть не только общий документ, но и релизный Slack-канал. Команда обсуждает текущую стадию релиза в Slack, основываясь на общем документе, и документ обновляется вместе с чатом.

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

Проинформируйте всех заинтересованных лиц

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

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

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

Технический персонал (инженеры поддержки или сторонние разработчики) предпочтут получать технические обновления с точными данными об изменениях в железе или ПО – например, о версии обновленной базы данных.

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

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

Предоставление заинтересованным лицам ценной информации вовремя

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

Дата старта релиза критически важна, а также проста для информирования. Сообщить заинтересованным лицам, когда планируется релиз, можно, как правило, одним сообщением или письмом. Важно быть внятным и точным, когда речь идет о времени – это может включать временные зоны для распределенных команд или различные форматы времени для команд с разными локализациями. Также сообщайте о других связанных событиях – например, множественном обновлении серверов в слегка различное время. Зачастую лучше давать больше описаний. Сообщить заинтересованным лицам, что релиз запланирован на "8 вечера в пятницу, 15 числа" лучше, чем сказать "Вечер пятницы", "Пятница после работы" или, о ужас, "пятнадцатого вечерком". Внятность очень важна в этом случае. Абсолютное время лучше, чем относительное.

Причина того, почему планируется релиз, также может быть полезной для заинтересованных лиц. Релизы по известному расписанию важны для них. полезно дать им возможность высказаться или сообщить об известных им проблемах, которые могут повлиять на релиз. Даже если это хотфикс, известное расписание для пострелизных исправлений – тоже важная информация. К примеру, если релиз запланирован ежемесячно на 15 число, сообщение об этом поможет новым участникам и напомнит существующим, почему они столкнутся с изменениями в приложении. Если релиз идет не по расписанию, пояснение, почему он происходит, будет полезно всем заинтересованным лицам. Например, релиз содержит исправление критического бага – это важная информация для многих из них. Иногда даже краткого описания в духе "приложение нуждается в обновлении" вполне достаточно.

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

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

Тестирование релиза

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

Верификация релиза

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

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

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

Базовое релизное тестирование

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

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

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

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

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

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

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

Используйте автоматизацию мудро

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

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

В релиз!

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

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