Процесс тестирования
Тестовые окружения: Local, Dev, QA, Stage, UAT и Prod
Окружение (environment), или стенд, – это набор программных и аппаратных средств, на котором развёрнуто приложение. Код проходит окружения по цепочке: Local на компьютере разработчика, Dev для первых проверок, QA для основного тестирования, Stage как копия продакшена для регресса перед релизом, иногда UAT для приёмки и Prod, где работают пользователи. Тестировщик больше всего времени проводит на QA и Stage, а на проде ограничивается смоуком и выборочной проверкой нового.
- QA и Stage
- новое тестируют на QA, регресс перед релизом гоняют на Stage
- Код-фриз
- на Stage перед релизом попадают только исправления критичных багов
- Бесплатно
- урок с заданиями в моём базовом курсе
Что такое окружение и развёртывание
Окружение – комплекс программных и аппаратных средств, на котором запускают приложение. Его ещё называют средой, стендом или environment, и всё это одно и то же. В глоссарии ISTQB тестовое окружение (test environment) понимается шире: туда входят оборудование, инструменты, симуляторы и всё, что нужно для проведения тестов. Поэтому инструменты тестировщика я тоже отношу к тестовой среде, только к другой её части.
Развёртывание, или деплой (deployment), – это установка и запуск кода в окружении: на своём компьютере или на удалённом сервере, облачном или физическом. Окружения входят в процесс CI/CD, то есть непрерывной интеграции и доставки, при котором изменения кода можно в любой момент доставить пользователю.
Названия окружений нередко совпадают с названиями веток в Git, из которых на них разворачивают код. Набор и имена стендов на каждом проекте свои, и ниже описана типичная цепочка.
Окружения по порядку: от Local до Prod
В названии моего ролика четыре окружения, а в разборе их шесть: между Dev и Stage стоит QA, а перед продакшеном иногда появляется UAT.
Local
Разворачивается на компьютере. Здесь работают разработчики, которые запускают юнит- и компонентные тесты отдельных функций и методов. Тестировщик тоже иногда поднимает приложение у себя, например чтобы проверить функцию без интернета. Обычно для этого клонируют код из репозитория, скажем на GitHub, и запускают его в Docker несколькими командами по инструкции проекта. Открывают локальное окружение по адресу localhost или 127.0.0.1, часто с номером порта.
Dev
Песочница (sandbox) разработчиков на удалённом сервере, где с приложением можно делать что угодно. Разработчики проверяют здесь свою работу перед тем, как отдать её в тестирование. Если на отдельный стенд для тестирования нет бюджета, тестировщики тоже работают на Dev. Адрес обычно отличается приставкой dev в доменном имени.
QA (Test)
Главное окружение тестировщика. Сюда приходит сборка, которую разработчики считают готовой, и тестирование начинается со смоука. Потом проверяют критический путь, то есть функции, которыми пользуются каждый день, позитивными и негативными тестами, а найденное оформляют баг-репортами.
Stage (Pre-prod)
Предрелизное окружение со стабильной сборкой, которое максимально повторяет продакшен. Здесь проводят регрессионное тестирование, обычно за несколько дней до релиза. В это время действует код-фриз, и на Stage попадают только исправления критичных багов.
UAT
Окружение для приёмочного тестирования, которое есть далеко не везде. Пример: программу для юристов проверяет рабочая группа юристов и подтверждает, что критерии приёмки выполнены. Другой вариант – бета-тест игры, которую перед релизом дают ограниченному числу игроков. UAT может стоять перед продакшеном или жить отдельно от цепочки.
Prod (Production)
Рабочее окружение, где приложением пользуются настоящие пользователи. К этому моменту критичные баги должны быть исправлены на предыдущих окружениях.
Что тестировщик делает на QA-стенде
Сборку (build), то есть промежуточную версию продукта, разворачивают на стенд инструментом вроде Jenkins. В нём заранее указано, из какого репозитория Git взять код и к какому серверу базы данных подключиться, и остаётся запустить сборку и проследить, чтобы она прошла без ошибок. Если что-то сломалось, читают логи. На действующем проекте всё уже настроено, и тестировщику, особенно ручному, глубоко погружаться в настройку не нужно.
После развёртывания проводят смоук-тест и решают, можно ли работать со сборкой дальше. Если смоук пройден, идут по критическому пути с позитивными и негативными проверками. На негативные не всегда хватает времени, но пару стоит провести обязательно.
Стенды подключают к тестовым версиям внешних сервисов. Интернет-магазин на QA обычно работает с тестовым режимом платёжного сервиса: заказ оплачивают тестовой картой из документации провайдера, и деньги не списываются. После развёртывания стоит убедиться, что стенд смотрит именно туда. Если в настройки QA попали боевые ключи, тестовая карта не пройдёт, а оплата своей картой спишет настоящие деньги. Это критичный дефект конфигурации, и о нём сообщают сразу.
Когда тестировщиков несколько, а задач много, одного стенда не хватает, и компания создаёт второй, если есть деньги. Чтобы стенды не простаивали и не были заняты впустую, задачи копят и разворачивают пачкой по расписанию, например в понедельник, среду и пятницу. Функции к тому же полезно проверять вместе: так видно, как они взаимодействуют.
Стенд делят через общий чат тестировщиков, где пишут "QA-стенд занят" и "QA-стенд свободен". Иначе коллега запустит новое развёртывание посреди вашего тестирования и затрёт данные вместе с результатами.
Stage, код-фриз и регресс перед релизом
Когда на QA всё проверено и критичные баги исправлены, сборку переводят на Stage. Это стабильная версия, которая максимально повторяет продакшен, поэтому окружение называют ещё предрелизным. Здесь проводят регрессионное тестирование и проверяют, что новый код и исправления не сломали остальное. Иногда регресс делают прямо на QA-стенде, но отдельное окружение для него лучше.
На время регресса объявляют код-фриз (code freeze). Разработчики продолжают работать в своих ветках над следующими задачами, но вливать изменения в ветку будущего релиза не могут. Исключение составляют исправления критичных багов, найденных на регрессе. Их чинят и возвращают на QA или сразу на Stage, смотря сколько есть времени.
Если регресс прошёл, команда даёт добро на релиз. На проде полное тестирование не повторяют. Я считаю это плохой и даже опасной практикой: если прод так отличается от Stage, что всё приходится проверять заново, процесс устроен неправильно. Хватает минимального смоука по главным функциям и выборочной проверки того, что вошло в релиз.
Пример: одна задача проходит все окружения
Допустим, в приложении переделали сброс пароля. Вот где и что с ним происходит.
Local
Разработчик пишет новый код и прогоняет юнит-тесты на своём компьютере.
Dev
Код уходит на сервер разработчиков, и разработчик проверяет, что письмо со ссылкой отправляется.
QA
Тестировщик занимает стенд, разворачивает сборку и проводит смоук. Затем проверяет сброс пароля позитивными и негативными тестами: верная почта, несуществующая почта, просроченная ссылка. Если ссылка из письма не открывается, он заводит баг, а после исправления делает ретест на новой сборке.
Stage
Перед релизом объявлен код-фриз. Регресс проверяет соседние функции: вход с новым паролем, отказ во входе со старым и регистрацию, которая отправляет письма тем же способом.
Prod
После релиза проводят короткий смоук: приложение открывается, вход работает, письмо для сброса пароля приходит.
Видеоурок, шпаргалки и задания
Я разбираю окружения в ролике "Тестовые окружения для тестировщика" на YouTube. Там я вспоминаю, как на первом рабочем собрании не понимал слов "стейдж", "стабильный билд" и "код-фриз", потому что на курсе об окружениях не рассказывали. В бесплатном базовом курсе по тестированию тема идёт уроком "Тестовые окружения", и после теории в нём есть задания.
Шпаргалка по CI/CD показывает конвейер по стадиям и окружения, через которые проходит сборка. Шпаргалка о прогоне билда объясняет, где в работе со сборкой стоят смоук, ретест и регресс.
Курсы по теме
Вопросы и ответы
Какие бывают тестовые окружения?
Типичная цепочка такая: Local на компьютере разработчика, Dev для проверок разработчиков, QA (Test) для основного тестирования, Stage (Pre-prod) для регресса перед релизом, иногда UAT для приёмочного тестирования и Prod, где работают пользователи. Набор и названия на каждом проекте свои.
Чем Stage отличается от QA?
На QA тестируют новые задачи: смоук, критический путь, позитивные и негативные проверки, и сборки там меняются часто. Stage – стабильная предрелизная копия продакшена. На ней перед релизом проводят регресс, и во время код-фриза туда попадают только исправления критичных багов.
Можно ли тестировать на продакшене?
Повторять на проде всё тестирование – плохая и опасная практика. После релиза проводят короткий смоук главных функций и выборочно проверяют то, что вошло в релиз. Остальное проверяют раньше, на QA и Stage.
Что такое код-фриз?
Период перед релизом, когда в релизную ветку не вливают новый код. Разработчики продолжают работать в своих ветках, а на Stage попадают только исправления критичных багов, найденных на регрессе.
Окружение, среда и стенд – это одно и то же?
Да, все три слова и английское environment означают место, где развёрнуто приложение. Тестовой средой иногда называют ещё и набор инструментов, которыми пользуется тестировщик.
Что такое localhost?
Адрес собственного компьютера, он же 127.0.0.1. По нему открывают приложение, развёрнутое локально, обычно с номером порта через двоеточие.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.