Книга: Руководство по DevOps

Автоматизируйте как можно больше тестов

Наша цель — найти как можно больше ошибок в коде с помощью наборов автоматизированных тестов, снижая зависимость от тестирования вручную. В своей презентации «В заботе о циклах обратной связи и их поддержании» (On the Care and Feeding of Feedback Cycles) на конференции Flowcon в 2013 г. Элизабет Хендриксон отмечала: «Хотя тестирование может быть автоматизировано, создание качества автоматизировать невозможно. Выполнение вручную тестов, нуждающихся в автоматизации, — пустая трата человеческого потенциала».

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

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

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

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

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

Гэри Грувер, ранее работавший вице-президентом по качеству разработок, релиза ПО и эксплуатации компании Macys.com, так описывал свои впечатления: «На нашем сайте электронной коммерции крупного розничного продавца мы перешли от 1300 тестов, выполняемых вручную каждые десять дней, к десяти автоматизированным, запускаемым при каждой записи изменений кода. Гораздо лучше выполнить несколько надежных тестов, чем много ненадежных. С течением времени мы расширили этот набор до сотен тысяч автоматизированных тестов».

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

Оглавление книги