Ответ
На этапе планирования создаются документы, определяющие стратегию, объём и процесс тестирования.
Ключевые артефакты:
- Тест-план (Test Plan): Основной стратегический документ.
- Детализированные тест-кейсы/тест-сьюты: Конкретные сценарии проверок.
- Чек-листы (Checklists): Для регрессионного и смоук-тестирования.
- Матрица трассируемости (RTM): Для контроля покрытия требований.
- План по рискам (Risk Assessment): Приоритизация областей тестирования.
Структура тест-плана (краткий пример):
1. Область тестирования (Scope)
- Что будет тестироваться (модули A, B, C).
- Что НЕ будет тестироваться (модуль D, нагрузочное тестирование).
2. Подход (Testing Approach)
- Типы тестирования: функциональное, интеграционное, регрессионное.
- Методы: ручное, автоматизированное (70/30).
3. Критерии начала/окончания тестирования (Entry/Exit Criteria)
- Entry: все билды проходят smoke-тесты, среда готова.
- Exit: все критические баги исправлены, покрытие >95%.
4. Ресурсы и расписание (Resources & Schedule)
- Команда: 2 QA-инженера, 1 автоматизатор.
- Окружение: Dev, Staging.
- Дедлайны для каждого этапа (тест-дизайн, выполнение, регресс).
5. Управление рисками (Risk Management)
- Риск: нестабильность API третьей стороны.
- Митигация: mock-сервисы для изолированного тестирования.
6. Отчётность (Reporting)
- Ежедневные стендапы, weekly-отчёты о статусе и метриках.Документация должна быть живой — регулярно обновляться по ходу проекта.
Ответ 18+ 🔞
Да ты посмотри, какая красота, блядь! Этап планирования, сука. Это ж как разведка перед боем, только вместо карты и свистков — бумажки, которые потом все равно никто читать не будет, но хуй с ним, делать-то надо!
Вот сидишь ты, такой, и думаешь: «С чего бы начать, чтобы потом не оказаться, блядь, крайним?» А начинать надо с документов, которые определяют, что мы вообще будем делать, сколько и как. Стратегию, объём и процесс, ёпта! Без этого — полный пиздец и хаос, все бегают как тараканы, а продукт горит синим пламенем.
Вот эти самые священные артефакты, без которых — нихуя:
- Тест-план (Test Plan): Это, блядь, наша библия, конституция и устав караульной службы в одном флаконе. Главный документ, от которого всё пляшет.
- Детализированные тест-кейсы/сьюты: А это уже, сука, конкретные инструкции: «Нажми сюда, получишь вот это, а если получишь по ебалу — пиши баг».
- Чек-листы (Checklists): Для ленивых, но умных. Когда делать полный регресс — это овердохуища времени, а проверить ключевые точки — в самый раз. И для смоука, чтобы билд не развалился на первом же шаге.
- Матрица трассируемости (RTM): Хитрая хуйня, чтобы начальство не приебалось: «А вы вот это требование проверили?». А ты такой: «Проверил, блядь, вот тест-кейс ID-123, ссылка на баг-репорт, всё покрыто, иди нахуй».
- План по рискам (Risk Assessment): Чтобы заранее знать, где нас ждёт самый жирный пиздец, и сконцентрировать силы там. Приоритизация, мать её.
А теперь, сука, смотри, как примерно выглядит этот самый тест-план. Не пугайся, это не «Война и мир»:
1. Область тестирования (Scope)
- Что будем мучать: модули A, B, C.
- Что трогать не будем, ибо похуй или не успеем: модуль D, нагрузочное тестирование.
2. Подход (Testing Approach)
- Как будем мучать: функционально, на интеграцию, регрессом.
- Чем будем мучать: в основном руками (70%), но кое-что автоматом (30%), чтобы не сойти с ума.
3. Критерии начала/окончания (Entry/Exit Criteria)
- Когда начинаем: когда билд не падает от смоук-тестов и среда не глючит.
- Когда заканчиваем: когда все критические баги пофикшены, а покрытие требований выше 95%. (Мечтать не вредно, блядь).
4. Ресурсы и расписание (Resources & Schedule)
- Кто будет мучать: 2 ручных тестировщика и 1 автоматчик, который вечно занят.
- Где будем мучать: среда Dev (всё падает) и Staging (всё тормозит).
- Когда будем мучать: дедлайны на дизайн тестов, основное выполнение и регресс.
5. Управление рисками (Risk Management)
- Риск: API сторонней конторы нестабилен, как алкоголик в запое.
- Что делать: готовим mock-сервисы, чтобы тестировать в изоляции от этого цирка.
6. Отчётность (Reporting)
- Куда докладываем: ежедневные стендапы (где все делают вид, что работают) и еженедельные отчёты с цифрами и статусами.И главное, запомни, чувак: эта документация должна быть живой, блядь! Не написал и забыл в каком-нибудь Confluence, куда даже тараканы не заходят. Её надо обновлять, когда проект меняется, а он меняется всегда. Иначе получится, что ты по плану 1999 года пытаешься запустить ракету на Марс. Пиздец и разбитый корпус.