# QA Strategy

> Выбрать стратегию проверки по рискам, объём регрессии и подтверждаемые критерии готовности для существенного изменения. Применять для решения, что и на каком уровне тестировать; уже выбранные проверки реализуются средствами автоматизации или профильного тестирования.

- Skill: `fbakiyev/qa-strategy` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/qa-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/qa-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/qa-strategy

---


# Стратегия QA

## Сформулировать риск

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

## Выбрать доказательства

- Для каждого важного сценария задай независимое правило или наблюдение, определяющее правильность. Ожидаемое значение, скопированное из реализации, скриншот без проверки поведения и «выглядит быстро» — недостаточные критерии.
- Выбирай самый низкий уровень, способный обнаружить сбой, и добавляй проверки границ только по необходимости. Модульный тест не доказывает поведение транзакции базы данных, а десятки браузерных тестов излишни для арифметики, уже проверенной напрямую.
- Включай различающий контрпример: переставленные ответы, повторные данные, смешанные версии приложения, запрещённый доступ к чужой записи или другой относящийся к риску случай. Объясни, почему тест отвергнет дефектное поведение, а не просто выполнит код.
- Отличай корректность продукта от точности воспроизведения окружения. Хранение в памяти, заглушки интеграций или отсутствие данных масштаба production могут оставить конкретные риски непроверенными, даже если все доступные тесты прошли.
- Делай критерии готовности наблюдаемыми и ограниченными по области. Отличай обязательные проверки, полезные последующие действия и недоступные доказательства; не позволяй зелёному подмножеству незаметно подменять непроверенную миграцию или восстановление.

Используй исследовательскую или прицельную ручную проверку, если она даёт больше информации, чем хрупкая автоматизация. Приоритет воспроизводимой автоматизации определяется ценностью регрессии, а не целевым числом тестов или заявлением об исчерпывающем покрытии.

## Подготовить стратегию

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

Если запрошено выполнение, используй подходящий навык тестирования и записывай фактические результаты отдельно от плана. Добавляй обязательные проверки CI только когда их достоверность, длительность и окружение подходят процессу проекта; сам план тестирования не разрешает изменение общей конфигурации CI.

`templates/test-plan.md` необязателен и используется при доступном репозитории. Не принимай непроверяемые критерии приёмки и не требуй посторонних процессных документов для завершения стратегии.