fbakiyev Стратегия QA
Сформулировать риск
Изучи критерии приёмки, изменяемые границы, затронутых пользователей и доступные окружения. Назови конкретный сбой и его последствие: повторный эффект, недоступный элемент управления, несовместимый читатель, потерянное обновление или другой риск, подтверждённый изменением. Не привязывай все категории тестов к каждой функции.
Выбрать доказательства
- Для каждого важного сценария задай независимое правило или наблюдение, определяющее правильность. Ожидаемое значение, скопированное из реализации, скриншот без проверки поведения и «выглядит быстро» — недостаточные критерии.
- Выбирай самый низкий уровень, способный обнаружить сбой, и добавляй проверки границ только по необходимости. Модульный тест не доказывает поведение транзакции базы данных, а десятки браузерных тестов излишни для арифметики, уже проверенной напрямую.
- Включай различающий контрпример: переставленные ответы, повторные данные, смешанные версии приложения, запрещённый доступ к чужой записи или другой относящийся к риску случай. Объясни, почему тест отвергнет дефектное поведение, а не просто выполнит код.
- Отличай корректность продукта от точности воспроизведения окружения. Хранение в памяти, заглушки интеграций или отсутствие данных масштаба production могут оставить конкретные риски непроверенными, даже если все доступные тесты прошли.
- Делай критерии готовности наблюдаемыми и ограниченными по области. Отличай обязательные проверки, полезные последующие действия и недоступные доказательства; не позволяй зелёному подмножеству незаметно подменять непроверенную миграцию или восстановление.
Используй исследовательскую или прицельную ручную проверку, если она даёт больше информации, чем хрупкая автоматизация. Приоритет воспроизводимой автоматизации определяется ценностью регрессии, а не целевым числом тестов или заявлением об исчерпывающем покрытии.
Подготовить стратегию
Верни компактное соответствие риск → сценарий → уровень → независимый критерий правильности → критерий готовности, а также требования к данным или окружению и существенные пробелы. Для небольшого изменения весь план может состоять из нескольких случаев в ответе.
Если запрошено выполнение, используй подходящий навык тестирования и записывай фактические результаты отдельно от плана. Добавляй обязательные проверки CI только когда их достоверность, длительность и окружение подходят процессу проекта; сам план тестирования не разрешает изменение общей конфигурации CI.
templates/test-plan.md необязателен и используется при доступном репозитории. Не принимай непроверяемые критерии приёмки и не требуй посторонних процессных документов для завершения стратегии.