Home

Автор: Джейк Бартлетт (Jake Bartlett).

Оригинал статьи: http://www.ministryoftesting.com/2016/02/6-questions-to-ask-before-releasing-software/

Перевод: Ольга Алифанова

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

Как вы определяете, что вы можете выпускать ваше детище в релиз? Кто скажет "Поехали" и махнет рукой? Что именно нужно обязательно сделать перед релизом?

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

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

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

Чем лучше вы и ваши клиенты готовитесь к релизу, тем счастливее вы станете.

Вот на что стоит обратить внимание, когда релиз не за горами:

1. Налажены ли процессы и коммуникации, перенимаете ли вы передовой опыт?

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

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

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

2. Что было и не было протестировано, как именно, почему?

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

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

Не менее важно понимать, как именно тестировалось ПО. Если релиз-кандидат протестирован плохо - вы рискуете столкнуться с проблемами после релиза.

3. Видел ли дизайнер финальный дизайн/релиз-кандидат?

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

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

4. Проводилось ли приемочное тестирование?

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

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

5. Учтены ли такие внешние факторы, как маркетинговые акции и праздники?

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

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

6. Готова ли к релизу ваша служба поддержки?

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

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

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

Заключение

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

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

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

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

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