Мы часто слышим от своих коллег, что они хотели бы выпускать обновления как можно быстрее и с минимальными затратами. Когда команда завершает работу над новой функцией, они стремятся сразу же предоставить её клиентам, чтобы получить обратную связь.
К сожалению, в некоторых компаниях им приходится ждать запланированного выпуска, чтобы начать работу. В более гибких компаниях этот процесс может происходить каждые две недели, что, безусловно, лучше, чем традиционные ежеквартальные релизы, но всё же не так быстро, как хотелось бы.
Большинство организаций стремятся успешно внедрить концепцию, о которой мы говорили в начале: непрерывную интеграцию и непрерывную доставку (CI/CD). Вы, вероятно, не впервые слышите о CI/CD: на эту тему написаны тысячи статей, книг и блогов. Однако почему CI и CD стали настолько популярными, а их менее известный «брат» — непрерывное тестирование (CT) — остаётся в тени?
Прежде чем углубиться в детали CI/CD и CT, давайте вспомним основные определения этих трех концепций.
Непрерывная интеграция — это процесс, при котором разработчики вносят небольшие изменения в код и часто проверяют их в общем репозитории.
Непрерывная доставка — это расширение непрерывной интеграции. Когда код возвращается из разработки, автоматизированные процессы тестируют его и отправляют в определенные среды.
Непрерывное тестирование — это процесс выполнения автоматических тестов на протяжении всего конвейера CI/CD, что гарантирует успешное внедрение кода.
Прошли те времена, когда можно было сказать: «Это небольшое изменение в одну строчку, не требует тестирования».
В мире непрерывного тестирования разработчики вносят изменения в код и отправляют его в репозиторий с исходниками. Модульные тесты выполняются автоматически. Однако вместо того, чтобы кто-то вручную развертывал этот код в тестовой среде (без каких-либо знаний о состоянии сборки), запускается другой набор автоматических тестов. Если они проходят, код будет развернут! Если нет — это повод для беспокойства.
Этот процесс сборки, тестирования и развертывания может происходить каждую ночь с помощью автоматизации. Каждый день, приходя в офис или находясь на удаленке, вы знаете, что вас ждёт только что развернутая сборка, прошедшая заранее определенный уровень проверок. CT — это основа, которая связывает всё это воедино.
По мере того как различные наборы автоматических скриптов дают добро на продвижение кода, очень важно, чтобы ручные тестировщики были вовлечены в процесс и им доверяли тестировать появляющиеся новые функции и они помогали поддерживать набор регрессионных тестов.
Непрерывное тестирование позволяет вам и тестировщику, получать обратную связь от разработчиков как можно быстрее. Традиционно тестирование завершается как последний шаг перед развертыванием. Постоянная проверка кода на протяжении всего жизненного цикла позволяет команде быстро получать обратную связь и находить ошибки на более ранних этапах цикла разработки.
Независимо от вашей должности, каждый из нас может стать лидером. Взгляните на себя: вы здесь, читаете блоги и изучаете материалы. Лидеры помогают формировать и продвигать стратегию, и наша задача как лидеров в области контроля качества — согласовать нашу стратегию контроля качества с общими целями бизнеса.
Спойлер: наша цель — как можно быстрее предоставлять клиентам новые функции, и это не просто слова. Если ваша команда DevOps тратит часы на автоматизацию каждой части вашего конвейера доставки, только чтобы понять, что ручное тестирование все еще необходимо, вас может ждать некоторое разочарование.
Обеспечение качества — это ключевой фактор, именно поэтому нас здесь ценят. Давайте углубимся и обсудим, как вы могли бы лучше подготовить свою стратегию непрерывного тестирования, чтобы, когда CI/CD начнет стучаться в вашу дверь, вы были готовы его принять.
Производительность вашего приложения: Соответствует ли система базовым стандартам производительности? Со временем снижение производительности может стать заметным, и учет этого фактора при каждом развертывании — это важное условие для предотвращения негативных ситуаций. Тем не менее, регулярные тесты производительности по-прежнему необходимы.
1. Критические пути тестирования: Были ли учтены пути тестирования, критически важные для вашего бизнеса? Может ли кто-нибудь выбрать ваш продукт и заплатить вам за него деньги? Может ли он подписаться на вашу рассылку новостей? Какими бы ни были ваши критически важные для бизнеса пути, убедитесь, что они учтены.
2. Новый код: Учитывается ли новый код, который вы внедряете? Не выпускайте новую функцию без надлежащего тестирования!
3. Автоматизированные скрипты: Обрабатывают ли ваши автоматизированные скрипты тестовые данные?
4. Тестовые среды: Настроены ли у вас соответствующие тестовые среды для учета этого тестирования?
5. Оповещения: Есть ли в вашем конвейере соответствующее оповещение в случае обнаружения дефекта?
6. Тесты: Действуют ли ваши тесты как стоп-кран и не дают ли они плохому коду продвинуться дальше?
7. Поддержка скриптов: Как вы будете поддерживать свои скрипты? Ложные срабатывания могут стать причиной сбоев в непрерывной работе!
8. Сценарии: Выполняются ли ваши сценарии за достаточное количество времени, чтобы мечта вашей компании о CI/CD стала реальностью? Главное — понять, что именно нужно тестировать на каждом этапе. Если вы будете выполнять 2500 сценариев, ваше непрерывное тестирование будет больше похоже на регрессионное.
9. Инструменты: Заранее изучите, какие инструменты подходят для вашей организации и команды QA. Будьте готовы представить их руководству, чтобы учесть QA при планировании стратегии CI/CD. Инструменты автоматизации с открытым исходным кодом, такие как Selenium и Appium, позволяют быстро тестировать на разных платформах, но есть множество других инструментов, которые могут подойти лучше.
Если бы ваши IT-руководители обратились к вам сегодня с предложением начать ежедневно поставлять программное обеспечение клиентам, стал бы отдел контроля качества ключевым элементом или препятствием для этой инициативы? В конце концов, речь идёт о качестве — или так должно быть. Не стоит жертвовать качеством продукта ради внедрения стратегии CI/CD, если ваша команда контроля качества не готова к этому.