Новая фича: от тест-анализа до финального тестирования

🎯 Задача

Провести новую фичу через полный цикл качества в Test IT: начать тестирование на этапе требований (shift‑left), подготовить чек‑лист или тест‑кейсы, запустить прогон и принять обоснованное решение о готовности к релизу.

💡 Решение

Подключим QA к работе с фичей еще до начала разработки, оформим тест-анализ, подготовим чек-листы / тест-кейсы и тест-план, свяжем ручные и автоматические проверки, затем используем результаты прогонов, SLA по дефектам и quality gate для финального решения по поставке.

Каждый блок Результат в рецепте — это quality gate. Не переходите к следующему шагу, пока предыдущий результат не достигнут.

Перед началом работы

📝 Вам потребуются:

• Новая фича (story / feature / task в таск-трекере), которая влияет на функциональность продукта
• Системная роль не ниже, чем Пользователь и проектная роль с возможностями редактирования сущностей
• При необходимости — участие команды автоматизации для разработки или актуализации E2E / API‑тестов

⏱ Время: Зависит от объема и сложности фичи — от нескольких часов на тест‑анализ и подготовку чек‑листа до нескольких дней на полный цикл

Шаг 1: создаем задачу на тест‑анализ

ℹ️ Шаг 1 выполняется до работы в Test IT — это подготовительный этап, который определяет, что вы будете тестировать.

Тест-анализ обязателен для любого изменения, влияющего на функциональность продукта. Его цель — подключить QA до начала разработки, выявить риски и согласовать стратегию тестирования.

🛠️ Мы рекомендуем сделать следующее:

1. Изучите требования по фиче: что именно меняется, зачем нужна фича и как она влияет на текущий пользовательский путь.
2. Уточните техническое решение: какие компоненты и эндпойнты затрагиваются, как передаются и хранятся данные, есть ли фича‑флаги.
3. Зафиксируйте в задаче тест‑анализа:
   • Затрагиваемые компоненты — перечислите области системы, которые изменяются или могут пострадать.
   • Ссылку на тест‑план / чек‑лист в Test IT — добавите после следующего шага.
   • Перечень фича‑флагов — укажите используемые флаги и кратко опишите, что они делают.
   • Итог тест‑анализа — обязательный пункт: какие есть замечания к фиче, что нужно доработать, какие риски зафиксированы.
   • Оценку автоматизации — определите, нужны ли E2E / API-автотесты для новой функциональности. Если да — создайте заявку на автоматизацию в SDET-команду прямо из задачи тест-анализа.
     

✅ Результат: Задача на тестирование сформулирована в таск-трекере. У команды есть общее понимание фичи, ее рисков и объема предстоящего тестирования.

Шаг 2: создаем чек‑лист в Test IT

ℹ️ Чек‑лист — это основной рабочий инструмент тест‑анализа. Он покрывает все ключевые проверки, не требует детализации до шагов и ожидаемых результатов. Чек-лист может быть финальным артефактом — его не обязательно конвертировать в тест-кейс. В Test IT чек-лист можно добавить в тест-план и запустить как полноценный набор проверок.

🛠️ Чтобы подготовить чек-лист:

1. В Test IT перейдите в библиотеку тестов и создайте новый чек‑лист для фичи.
2. Добавьте высокоуровневые проверки:
   • Основные пользовательские сценарии
   • Негативные сценарии и граничные случаи
   • Смежную функциональность, которая может пострадать от изменений
3. Скопируйте ссылку на чек‑лист и добавьте ее в задачу тест‑анализа.

✅ Результат: В Test IT есть чек‑лист с высокоуровневыми проверками по фиче, связанный с задачей тест‑анализа.

Шаг 3: добавляем чек‑лист в тест‑план и проходим тесты

🛠️ Мы рекомендуем следующий порядок действий:

1. Создайте тест‑план по фиче в Test IT или используйте существующий.
2. Добавьте в тестовый набор чек‑лист, созданный ранее. При необходимости добавьте чек‑листы или тест‑кейсы по смежному функционалу.
3. Опционально: Если для фичи написаны автотесты — добавьте их в тот же тест-план. В Test IT ручные и автоматические проверки отображаются в едином прогоне, что дает полную картину покрытия.
4. Назначьте конфигурацию (окружение, ОС, браузер и т.п.).
5. Назначьте исполнителей и приступайте к проверкам.

✅ Результат: Тест‑план сформирован, тестировщики назначены, команда проводит проверки по чек‑листу в Test IT.

Шаг 4: обрабатываем результаты и принимаем решение о релизе

ℹ️ После запуска прохождения тестов смотрим статусы тестов на странице тест-плана или вкладке Отчет.

🛠️ Чтобы запустить первый прогон:

🎉 Тесты пройдены успешно

🛠️ Если все проверки завершены успешно (дефектов не выявлено):

1. Убедитесь, что 100% тест‑поинтов имеют статус Успешен.
2. Зафиксируйте итог тест‑анализа в задаче: кратко опишите, что проверено, какие риски сняты.
3. В тест-плане укажите статус Завершен.
4. Передайте фичу на релиз — quality gate пройден.

✅ Результат: Фича протестирована, замечаний нет, команда готова к поставке.

🐛 Найдены дефекты

Часть проверок завершилась с ошибками — нужно зафиксировать дефекты и принять решение.

🛠️ Мы рекомендуем сделать следующее:

1. Создайте дефект прямо из проваленного пункта чек‑листа или тест‑кейса — шаги, окружение и вложения подтянутся автоматически.
   
2. Укажите корректный приоритет.

Примеры приоритетов и SLA

Приоритеты дефектов:

• Blocker — состояние, равное инциденту (или являющееся его причиной). Работоспособность основных функций заблокирована.
• High — серьезная ошибка, которая значительно снижает эффективность работы пользователей, но не блокирует ее (основные функции работают с ошибками или есть какой-то обходной путь (workaround) и/или временно можно исключить использование функционала для сохранения работы в системе).
• Medium — ошибка среднего приоритета, которая не блокирует, но мешает работе. Чаще всего находится в регулярно используемом функционале и мешает, но имеет простой workaround и/или функция выполняется с дополнительным действием.
• Low — незначительные дефекты, не влияющее или оказывающее малое влияние на пользователя. Мелкие ошибки на frontend-части или не влияющее на итоговый результат ошибки backend-части.

SLA (Service License Agreement, здесь — время реагирования) по исправлению дефектов — это неотъемлемая часть процесса разработки. Например:

• Blocker — 3 дня
• High — 14 дней
• Meduim — 90 дней
• Low — без SLA, в бэклог команды

Quality gate для релиза — все дефекты с приоритетом Blocker и High должны быть закрыты (политика zero critical bug, также zero crit).

3. После исправления вернитесь к проваленным пунктам или тестам и проведите ретест.
4. Когда все критичные дефекты закрыты — зафиксируйте итоги в задаче и принимайте решение по quality gate.
5. Если дефект уровня Blocker или High обнаружен на проде или пропущен на этапе регресса — проведите postmortem (метод 5 Почему; SLA: 7 рабочих дней).
   По итогам сформируйте 3 артефакта:
   • Задача с выводами и причиной пропуска
   • Актуализированный тест-кейс / чек-лист в Test IT, покрывающий пропущенный сценарий
   • Заявка на автоматизацию в SDET-команду (при необходимости)

✅ Результат: Все дефекты зафиксированы и обработаны по SLA, ретест проведен, zero crit подтвержден (нет открытых дефектов в статусе Blocker и High), команда приняла обоснованное решение о готовности к релизу.