Планирование тестирования

Updated Jul 2026

Организация тестовых наборов

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

Структура тестового набора

Организация по функциональным областям

Test Suites/
  Authentication/
    Login/
      TC-101: Login with valid credentials
      TC-102: Login with invalid password
      TC-103: Login with 2FA enabled
      TC-104: Login with expired session redirect
      TC-105: Login with social provider (Google, GitHub)
    Registration/
      TC-201: Register with valid data
      TC-202: Register with duplicate email
      TC-203: Register with weak password
      TC-204: Email verification flow
    Password Reset/
      TC-251: Request password reset
      TC-252: Reset with expired link
      TC-253: Reset with used link
  Checkout/
    Cart/
      TC-301: Add item to cart
      TC-302: Remove item from cart
      TC-303: Update quantity
      TC-304: Cart persists across sessions
    Payment/
      TC-401: Pay with credit card
      TC-402: Pay with PayPal
      TC-403: Apply valid coupon
      TC-404: Apply expired coupon (error handling)
      TC-405: Insufficient funds handling

Почему не организовывать по типу тестов?

# BAD: Organized by test type
Test Suites/
  Smoke Tests/
    Login smoke
    Checkout smoke
    Search smoke
  Regression Tests/
    Login regression
    Checkout regression
    Search regression
  Edge Cases/
    Login edge cases
    Checkout edge cases

Эта структура заставляет вас переключаться между папками при работе с одной функцией. Она также затрудняет ответ на вопрос «какие тесты покрывают оформление заказа?», потому что они разбросаны по трём папкам.

Анатомия тест-кейса

Хорошо написанный тест-кейс самодостаточен и однозначен. Любой член команды должен быть способен выполнить его без дополнительного контекста.

Минимальный тест-кейс

Расширенный тест-кейс (с параметрами)

Тестовые циклы и тестовые планы

Тестовые циклы

Тестовый цикл — это одно выполнение набора тест-кейсов. Вы создаёте новый цикл для каждого спринта, релиза или регрессионного прогона.

Sprint 23 Test Cycle
  Status: In Progress
  Start: 2024-01-15
  End: 2024-01-26
  Assigned: QA Team
  Test Cases: 145 total
    Passed: 98
    Failed: 12
    Blocked: 3
    Not Executed: 32

Тестовые планы

Тестовый план группирует несколько тестовых циклов для релиза. Он даёт общую картину выполнения тестов по спринтам.

Release 2.4.0 Test Plan
  ├── Sprint 22 Cycle (Complete: 142/142 passed)
  ├── Sprint 23 Cycle (In Progress: 98/145 passed)
  ├── Regression Cycle (Not Started)
  └── Performance Cycle (Scheduled)

  Overall Progress: 240/432 (55.6%)
  Blockers: 3 (SHOP-789, SHOP-801, SHOP-812)

Рабочие процессы выполнения тестов

Переходы статусов

Лучшие практики выполнения

1. Выполняйте в порядке приоритета: сначала запускайте дымовые тесты и тесты критического пути. Если они падают, расследуйте до запуска полного набора.
2. Документируйте сбои немедленно: не откладывайте документирование сбоев на конец дня. Заведите баг, пока контекст свежий.
3. Привязывайте сбои к дефектам: каждый упавший тест должен иметь привязанный баг-тикет. Это создаёт трассируемость.
4. Перезапускайте после исправлений: когда баг исправлен, перезапустите упавший тест и обновите его статус.
5. Обновляйте блокеры ежедневно: заблокированные тесты должны обсуждаться на стендапе. Не позволяйте им оставаться заблокированными весь спринт.

Поддержка тестовых наборов

Тестовые наборы требуют постоянной поддержки. Без неё они становятся устаревшими и ненадёжными.

Регулярные задачи обслуживания

Контроль версий для тест-кейсов

Если ваша платформа управления тестированием поддерживает версионирование, используйте его. Если нет, документируйте значимые изменения в истории или комментариях тест-кейса. Вы должны быть способны ответить на вопрос: «Как выглядел этот тест-кейс, когда мы тестировали релиз 2.3.0?»

Практическое упражнение

1. Проведите аудит текущей структуры вашего тестового набора. Организован ли он по функциональным областям или по типам тестов?
2. Выберите одну функциональную область и перечислите все покрывающие её тест-кейсы. Есть ли пробелы?
3. Создайте тестовый цикл для текущего спринта и выполните 10 тест-кейсов, документируя результаты
4. Найдите 5 устаревших тест-кейсов и обновите их
5. Найдите дублирующие тест-кейсы и консолидируйте их
6. Создайте тестовый план для следующего релиза с несколькими тестовыми циклами