Как создавал тест план

Процесс создания тест плана

Тест план — это документ, определяющий стратегию, сферу, расписание и ресурсы для тестирования. Я создаю его следующим образом:

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

Сначала я изучаю:

• Техническую спецификацию и требования к фиче
• Дизайны и mockup'ы (если веб/мобильное приложение)
• Архитектуру системы и зависимости
• Обратную совместимость и миграции
• Критичность функционала

Вопросы к разработчикам:

• Какие API endpoints затрагиваются?
• Какие схемы БД изменяются?
• Есть ли breaking changes для клиентов?
• Какие граничные случаи нужно учесть?

2. Определение сферы тестирования (Scope)

Что входит:

• Функциональное тестирование (все happy paths и error cases)
• API тестирование (для backend фич)
• Интеграционное тестирование (взаимодействие с другими сервисами)
• Регрессионное тестирование (проверка, что старое не сломалось)
• Performance тестирование (если критично)
• Security тестирование (для фич с доступом к данным)

Что исключаем:

• Нагруженное тестирование (если нет требований)
• Тестирование под конкретные ОС (если не требуется)
• Локализацию (если не требуется)

3. Определение тест сценариев

Для каждого требования:

• Happy path — стандартный успешный сценарий

  • Пользователь создаёт вопрос → сохраняется в БД → возвращается правильный ответ

• Negative scenarios — обработка ошибок

  • Пустое название вопроса → валидационная ошибка 400
  • Профессия не существует → 404
  • Нет прав доступа → 403

• Граничные случаи

  • Очень длинное название
  • Спецсимволы и emoji
  • Concurrent запросы
  • Пустые значения

• Состояния перехода

  • Создание → Редактирование → Удаление
  • Опубликование → Архивирование

4. Выбор методологии тестирования

Пирамида тестирования:

• Unit тесты (70%) — отдельные функции
• Integration тесты (20%) — взаимодействие компонентов
• E2E тесты (10%) — полный путь пользователя

Типы по покрытию:

• Покрытие требований
• Покрытие кодовых путей
• Граничные условия

5. Определение инструментов

• API тестирование: Postman, curl, pytest
• UI тестирование: Selenium, Playwright, Cypress
• БД тестирование: SQL запросы
• Performance: JMeter, Locust
• Security: OWASP ZAP, Burp Suite

6. Расписание и ресурсы

• Таймлайн: когда начинается, когда заканчивается
• Ресурсы: сколько QA нужно, окружения, инструменты
• Предусловия: тестовые данные, доступ

7. Критерии входа и выхода

Критерии входа:

• Код залит и собран
• Документация готова
• Тестовое окружение готово

Критерии выхода:

• Все тест кейсы выполнены
• Критичные баги зафиксированы
• Покрытие >= 80%
• Регрессия пройдена

8. Оформление документа

В Confluence или Google Docs структурирую по разделам:

Обзор: описание, критичность, даты, людей

Scope: что входит, что не входит

Тест сценарии: таблица с ID, описанием, шагами, ожидаемыми результатами

Инструменты: список использующихся инструментов

Риски: возможные проблемы и план действий

Результаты: отчёт о выполнении

Это обеспечивает структурированный подход и гарантирует полное покрытие требований.