в следующих главах). Все инженеры, работающие над продуктом, обязаны взять сборку канала разработки и использовать ее в реальной работе, чтобы проверить при продолжительном применении. Если сборка из канала разработки непригодна для нормальной работы, она отправляется обратно в канареечный канал. Это неприятная ситуация, которая потребует от инженеров серьезного пересмотра своей работы.
– Тестовый канал: сюда попадает лучшая сборка месяца – та, которая прошла наиболее продолжительное тестирование и которой доверяют инженеры. Сборку тестового канала можно выкатывать для внутренних пользователей. Это кандидат на сборку бета-канала, если покажет хорошие результаты при долгосрочном использовании. Однажды сборка тестового канала станет достаточно стабильной для использования внутри компании, а иногда мы даже передаем ее внешним сотрудникам и партнерам, которым может быть полезно раннее знакомство с продуктом.
– Бета-канал или канал выпуска: сюда попадают только стабильные сборки, успешно прошедшие внутреннее использование и удовлетворяющие всем критериям качества, установленным командой. Это первые сборки, которые доступны пользователям.
Метод «ползти, идти, бежать» помогает нам проводить тесты и экспериментировать с приложением на ранней стадии разработки. В дополнение к данным ежедневных автоматических тестов мы получаем ценную обратную связь от настоящих пользователей.
Виды тестов
Вместо того чтобы разделять тестирование на модульное, интеграционное и системное, мы делим все тесты на малые, средние и большие. Пожалуйста, не путайте с методом оценки из гибких методологий. Мы ориентируемся на охват, а не на размер теста. Малые тесты покрывают малые объемы кода, средние – объемы побольше и т. д. Любой инженер, независимо от своей роли, может заниматься любыми типами тестов. Их можно проводить в ручном или запускать в автоматическом режиме. Реальный опыт говорит, что чем меньше тест, тем скорее он будет автоматизирован.
На заметку
Вместо того чтобы разделять тестирование на модульное, интеграционное и системное, мы делим все тесты на малые, средние и большие, исходя из их охвата, а не размера.
Малые тесты чаще всего (хотя и не всегда) автоматизируются. Они исполняют код одной функции или модуля. Обычно они проверяют типичные функциональные проблемы, повреждение данных, неверные условия и ошибки, связанные со сдвигом значений на единицу. Малые тесты выполняются быстро, за несколько секунд и меньше. Как правило, их пишут разработчики, реже – разработчики в тестировании и почти никогда – инженеры по тестированию. Для выполнения малых тестов обычно нужна среда с подставными объектами и имитациями. Подставные объекты и имитации относятся к заглушкам (то есть заменителям реальных функций), они работают как заменители объектов в зависимостях – несуществующих, слишком ненадежных или затрудняющих эмуляцию ошибочных ситуаций. Мы расскажем об этом подробнее
