Home

Оригинальная публикация: http://www.networkworld.com/article/2944686/software/are-you-over-testing-your-software.html

Перевод: Анна Радионова

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

Тестирование релиз-кандидатов отнимает слишком много времени.

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

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

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

Такую практику как раз применяют технические специалисты Etsy.com, ресурса, представляющего собой что-то вроде онлайн маркета для мастеров, продажи которого составили более одного миллиарда долларов в 2013 году. В 2011 году в Etsy работало около ста программистов. Компания выросла с тех пор. В первый рабочий день новые программисты в Etsy должны изучить работу пайплайна, который включает внесение изменений, запуск проверок и деплой на продакшн. Etsy не единственная компания, использующая модель continuous delivery в разработке.

Секретные способы исключить регрессионное тестирование

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

Инструментарий тестирования. Многие инструменты способны выполнить проверку ПО, выполняя прогон основных сценариев и нахождение ключевых условий. Они применяются как для unit тестов или тестирования Web API, так и для end-to-end тестов, выполняющих проверку GUI. Нужно помнить: со временем end-to-end тесты начинают выполняться так долго, что становятся очень громоздкими. Критично важно отобрать нужные автоматизированные проверки; нужно отобрать их с целью уменьшения риска, чтобы выполнить их быстро и минимизировать трудоемкость отладки, которая необходима для поддержания актуальности тестов.

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

Полностью исключить ошибки регрессии. Continuous integration, при которой находятся постоянные ошибки, будет вести к постоянному исправлению и повторному тестированию. Чтобы эти стратегии работали, код, который является результатом процесса continuous integration, должен содержать меньше ошибок регрессии, чем принято отраслевым стандартом. И при должном уместном тестировании релиз-кандидата так и есть. Слишком часто “страховочная сетка” становится причиной плохой работы. Помните, что исключение тестирования релиз-кандидатов - путь к улучшению качества разработки.

Разрабатывайте отдельно развертываемые компоненты. Это правда: разработчики в Etsy делают деплой на продакшн в свой первый рабочий день. Код, который они пишут, очень незначительное изменение для добавления своего имени и фото на страницу About Us > Our Team page. Именно так. Эти изменения не затрагивают базу данных, веб сервисы, стили, библиотеки или код продуктового окружения; он ограничен областью стандартного HTML файла и картинки. Программист получает конкретные указания, поэтому худшее, что может случиться - это только, то, что страница может отображаться некорректно в течение нескольких минут.

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

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

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

Ниже Noah Sussman, веб разработчик/научный сотрудник, который разработал систему Continuous Integration (CI) в Etsy, приводит описание системы мониторинга в Etsy:

https://youtu.be/1W2vIE1nSxg

Автоматическое развертывание и откат. Мониторинг продуктового окружения - отличная идея; исправление багов на нем всего несколькими нажатиями клавиш или с помощью веб-приложения - даже лучше.

(Бонус) Флаг параметров настройки. Вместо патча или ручного отката существует возможность отключения фичи с помощью веб-приложения. Все, что нужно сделать разработчику - это вставить в код фичи конструкцию “if ()”, которая связана с библиотекой кода. Измените конфигурационный флаг на “Off” и новый функционал будет отключен. Статья Sussman Config Flags: A Love Story.

(Бонус) Инкрементальный раскат. Представьте, что флаги параметров настройки не глобальные, а привязаны к пользователю. Пользователям, которые хотят рискнуть (сотрудникам, их друзьям или членам семьи и заранее определенным первым пользователям продукта), доступен новый функционал. Пользователи пробной версии имеют доступ к новому функционалу, когда флаг конфигурации включен. Основная версия продукта остается для пользования более консервативными клиентами, которые используют ПО в целях бизнеса. Это наиболее стабильная, хорошо протестированная версия ситема. В своей книге How We Test Software at Microsoft Alan Page и его соавторы определяют это явление термином "тестирование на продакшне". У их команды имеется несколько версий приложения, установленного на разных серверах, и они переводят процессы на соответствующую платформу в зависимости от типа пользователя.

Сколько времени длится установление регрессионных циклов

Разработчик ПО Abby Bangser описывает проект, над которым недавно работала и на котором была возможность непрерывного деплоя. Для целей бизнеса команда хотела деплоить каждую итерацию, что является приемлемым. В конце итерации один из руководителей разработки попросил Bangser выполнить “пятиминутную проверку”, чтобы убедиться, что ничего не сломалось.

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

Почему? Почему пять минут представляют такую проблему?

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

Другой взгляд на темп разработки

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

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

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

Задайте себе сложные вопросы: как долго длится процесс сейчас? Какого темпа вы придерживаетесь? Добавляются ли к вашему процессу по пять минут каждые две недели или, наоборот, время сокращается? Что вы с этим планируете делать дальше?

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