Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation

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

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

...Файлы Makefile подвержены трудно обнаруживаемым ошибкам из-за того, что пробельные символы могут играть роль при определённых обстоятельствах. Например, в сценариях командной строки команды, передаваемые интерпретатору, должны быть предварены символами табуляции. Если вместо них стоят пробелы, сценарий не заработает.
Другой недостаток утилиты Make заключается в том, что она зависит от интерпретатора команд. Без него она ничего не может делать. В результате файлы Makefile специфичны для операционных систем. Чтобы заставить набор инструментов на основе Make работать в разных дистрибутивах UNIX, нужно приложить много усилий. Файлы Makefile фактически являются внешними файлами DSL (Domain Specific Language - предметно-ориентированный язык), которые не предусматривают расширение базовой системы (помимо определения новых правил), поэтому расширения вынуждены повторно создавать типовые решения без доступа к внутренним структурам данных Make.
Перечисленные проблемы, в сочетании с декларативной программной моделью Make, которая незнакома большинству разработчиков (они больше привыкли к императивному программированию), приводят к тому, что в запускаемых с нуля коммерческих проектах Make редко используется в качестве базового инструмента сборки.

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