# Чеклист QA

Практическая база для тестирования продукта: требования, тест-дизайн, тестовая среда, дефекты, регрессия, релизная приемка и автоматизация.

## Анализ требований

QA начинается не с кликов по интерфейсу, а с проверки требований на полноту, ясность, противоречия и тестируемость.

### Проверить требования на тестируемость

Найти неясные формулировки, пропуски и противоречия до начала тестирования.

**Что это дает:** Чем раньше QA задает вопросы, тем дешевле исправлять требования и дизайн.

**Как выполнить:**
- Прочитайте user story и acceptance criteria.
- Отметьте неоднозначные слова: быстро, удобно, корректно, понятно.
- Сформулируйте вопросы владельцу требования.

**Критерии приемки:**
- Неясные требования вынесены в список вопросов.
- Ответы зафиксированы в задаче.
- Критерии приемки можно проверить.

### Определить риски качества

Понять, где дефект нанесет наибольший вред пользователю или бизнесу.

**Что это дает:** Risk-based testing помогает тестировать глубже там, где цена ошибки выше.

**Как выполнить:**
- Определите критические пользовательские сценарии.
- Оцените вероятность и влияние дефекта.
- Выделите области для углубленных проверок.

**Критерии приемки:**
- Есть список рисков.
- Критические сценарии получили высокий приоритет.
- Команда согласовала уровень риска релиза.

### Подготовить тестовые данные

Создать данные для позитивных, негативных и граничных сценариев.

**Что это дает:** Хорошие тестовые данные делают проверки воспроизводимыми и сокращают время на ручную подготовку.

**Как выполнить:**
- Опишите нужные роли, статусы, тарифы, заказы и ограничения.
- Подготовьте данные для edge cases.
- Проверьте, что данные можно восстановить после теста.

**Критерии приемки:**
- Данные доступны в тестовой среде.
- Есть инструкция восстановления.
- Негативные сценарии не требуют ручного хака.

## Тест-дизайн

Тест-дизайн помогает выбрать достаточный набор проверок: не тестировать все подряд, но закрыть важные риски.

### Составить тест-кейсы для критических сценариев

Описать проверки так, чтобы их мог выполнить другой QA или разработчик.

**Что это дает:** Тест-кейсы сохраняют знание о продукте и помогают повторять проверки без потери качества.

**Как выполнить:**
- Выберите сценарии из требований и рисков.
- Опишите шаги, данные и ожидаемый результат.
- Укажите приоритет и тип проверки.

**Критерии приемки:**
- Критические сценарии покрыты.
- Ожидаемый результат конкретен.
- Тест-кейсы связаны с требованиями.

### Применить техники тест-дизайна

Использовать классы эквивалентности, граничные значения, таблицы решений и pairwise.

**Что это дает:** Техники тест-дизайна дают хорошее покрытие без бесконечного перебора вариантов.

**Как выполнить:**
- Разбейте входные данные на классы эквивалентности.
- Добавьте граничные значения.
- Для сложной логики используйте таблицу решений.

**Критерии приемки:**
- Проверки обоснованы техникой.
- Границы и комбинации покрыты.
- Лишние дубли удалены.

### Связать требования и проверки

Построить traceability между требованиями, тестами и дефектами.

**Что это дает:** Traceability показывает, что именно покрыто тестами и где изменение требования требует обновить проверки.

**Как выполнить:**
- Свяжите тест-кейсы с user stories.
- Отмечайте дефекты на уровне требования.
- Проверяйте покрытие перед релизом.

**Критерии приемки:**
- У требований есть связанные проверки.
- Понятны непокрытые зоны.
- Дефекты связаны с затронутым требованием.

## Выполнение проверок

На этапе выполнения QA проверяет продукт системно: с понятными данными, окружением, фиксацией результата и воспроизводимыми дефектами.

### Выполнить smoke-тесты

Быстро проверить, что сборка пригодна для дальнейшего тестирования.

**Что это дает:** Smoke экономит время: если базовые сценарии сломаны, глубокое тестирование бессмысленно.

**Как выполнить:**
- Определите минимальный набор критических сценариев.
- Выполняйте smoke после деплоя на тестовую среду.
- Останавливайте тестирование при критическом падении.

**Критерии приемки:**
- Smoke-набор опубликован.
- Результат зафиксирован.
- Критические падения сразу эскалированы.

### Оформить качественный bug report

Зафиксировать дефект так, чтобы разработчик мог быстро понять и воспроизвести проблему.

**Что это дает:** Хороший bug report сокращает цикл исправления и уменьшает количество уточнений.

**Как выполнить:**
- Укажите окружение, шаги, фактический и ожидаемый результат.
- Добавьте скриншот, видео, логи или request/response.
- Оцените severity и priority.

**Критерии приемки:**
- Дефект воспроизводится по шагам.
- Есть доказательство проблемы.
- Severity и priority объяснены.

### Провести retest исправленного дефекта

Проверить, что конкретный дефект исправлен и не повторяется на указанных данных.

**Что это дает:** Retest подтверждает исправление, но не заменяет регрессионную проверку соседних сценариев.

**Как выполнить:**
- Возьмите исходные шаги воспроизведения.
- Проверьте исправление на той же среде и версии.
- При необходимости добавьте смежные проверки.

**Критерии приемки:**
- Дефект закрыт только после успешного retest.
- Версия исправления указана.
- Смежные риски проверены или вынесены отдельно.

## Регрессия и релиз

Перед релизом важно проверить не только новую функцию, но и критические старые сценарии, которые могли сломаться.

### Спланировать регрессию

Выбрать набор проверок, который защищает важные старые сценарии перед релизом.

**Что это дает:** Регрессия снижает риск, что новая функциональность сломает работающие части продукта.

**Как выполнить:**
- Определите затронутые модули.
- Выберите critical path и интеграционные сценарии.
- Согласуйте время и владельцев регрессии.

**Критерии приемки:**
- Regression scope утвержден.
- Проверки привязаны к рискам релиза.
- Результат доступен команде.

### Подготовить QA verdict по релизу

Сформулировать состояние качества и риски, чтобы команда могла принять release decision.

**Что это дает:** QA verdict не решает за бизнес, но дает честную информацию о качестве и известных рисках.

**Как выполнить:**
- Соберите результаты smoke, regression и critical bugs.
- Опишите known issues и workaround.
- Дайте рекомендацию: go, go with risks или no-go.

**Критерии приемки:**
- Вердикт опубликован до релиза.
- Риски понятны stakeholders.
- Известные дефекты имеют владельцев.

### Разобрать дефекты после релиза

Понять, почему дефект дошел до production и как улучшить процесс.

**Что это дает:** Разбор production defects улучшает требования, тест-дизайн, автоматизацию и релизный контроль.

**Как выполнить:**
- Опишите путь дефекта от требования до релиза.
- Определите, какая проверка могла его поймать.
- Добавьте изменение в процесс или тестовый набор.

**Критерии приемки:**
- Root cause описан.
- Есть preventive action.
- Новый контроль добавлен в чеклист или автотесты.

## Автоматизация

Автоматизация полезна, когда она снижает повторяемую ручную работу и дает быстрый сигнал о регрессии, а не создает отдельный хрупкий проект.

### Выбрать кандидатов для автоматизации

Определить проверки, которые дают ценность при регулярном автоматическом запуске.

**Что это дает:** Автоматизировать стоит стабильные, повторяемые и важные сценарии, а не все ручные проверки подряд.

**Как выполнить:**
- Оцените частоту выполнения проверки.
- Проверьте стабильность функциональности.
- Сравните стоимость автоматизации и ручного выполнения.

**Критерии приемки:**
- Есть список кандидатов с приоритетом.
- Кандидаты связаны с рисками.
- Нестабильные зоны не автоматизированы преждевременно.

### Контролировать flaky-тесты

Выявлять нестабильные автотесты и быстро возвращать доверие к тестовому набору.

**Что это дает:** Flaky-тесты разрушают доверие к автоматизации: команда перестает реагировать даже на реальные падения.

**Как выполнить:**
- Отмечайте тесты, которые падают без изменения продукта.
- Изолируйте причины: данные, ожидания, сеть, асинхронность.
- Чините или временно выводите тест из quality gate.

**Критерии приемки:**
- Flaky-тесты видны в отчете.
- Есть владелец исправления.
- Quality gate не зависит от заведомо шумных проверок.

### Интегрировать проверки в CI

Запускать нужные уровни тестов автоматически на pull request, merge и релизных сборках.

**Что это дает:** CI дает быстрый сигнал о регрессии и помогает ловить проблемы до ручной приемки.

**Как выполнить:**
- Определите, какие тесты запускать на каждом событии.
- Разделите быстрые и долгие наборы.
- Публикуйте отчет так, чтобы команда видела причину падения.

**Критерии приемки:**
- CI запускает тесты по правилам.
- Отчет доступен команде.
- Падение quality gate блокирует небезопасный merge или релиз.