Как организовать тест-кейсы в тест-сьют и отслеживать результаты тестирования
Введение: зачем это нужно?
Представьте, что вы генеральный директор небольшой пекарни. У вас есть десятки рецептов: булочки, торты, багеты, круассаны. Если хранить все рецепты в одной беспорядочной стопке, повар будет тратить полчаса только на поиск нужного. Но если разложить рецепты по папкам — «Выпечка», «Торты», «Хлеб» — работа пойдёт в разы быстрее и ничего не потеряется.
С тест-кейсами (проверочными сценариями, которые мы составляли в предыдущих уроках) ситуация ровно такая же. Один тест-кейс — это один рецепт проверки. Когда их набирается двадцать, пятьдесят, сто штук, хаос неизбежен: непонятно, что уже проверили, что ещё нет, кто отвечает за какой раздел и сколько ошибок нашли за день.
Тест-сьют (от английского test suite — набор тестов) — это именно та «папка с рецептами»: структурированная коллекция тест-кейсов, объединённых общей темой или целью. А отслеживание результатов — это журнал, в котором повар отмечает: «рецепт проверен — получилось», «рецепт проверен — что-то пошло не так».
В этом уроке вы научитесь:
- понимать, что такое тест-сьют и как он устроен;
- группировать тест-кейсы по логике;
- фиксировать результаты тестирования (статусы прохождения);
- строить простую таблицу отслеживания вручную — без специальных программ;
- понимать, как это делается в реальных командах.
Теория
1. Что такое тест-сьют
Тест-сьют — это набор (список) тест-кейсов, которые логически связаны между собой. Простыми словами: это папка, в которую вы складываете похожие проверки.
Например, если вы тестируете интернет-магазин, можно создать такие тест-сьюты:
| Тест-сьют | Что проверяет |
|---|---|
| Регистрация и вход | Создание аккаунта, вход, восстановление пароля |
| Каталог товаров | Поиск, фильтры, карточка товара |
| Корзина | Добавление, удаление, изменение количества |
| Оплата | Ввод карты, применение купона, оформление заказа |
| Личный кабинет | История заказов, редактирование профиля |
Каждый тест-сьют — это отдельная тема. Внутри каждой темы — конкретные тест-кейсы.
Аналогия. Тест-сьют — как оглавление в учебнике. Оглавление (тест-сьют) разбито на главы (темы), каждая глава содержит параграфы (тест-кейсы), а каждый параграф — конкретные шаги и проверки.
2. Зачем группировать тест-кейсы
Без группировки возникают реальные проблемы:
- Потеря — тест-кейс написали, но потом не нашли среди других пятидесяти.
- Дублирование — два разных тестировщика написали одно и то же, не зная друг о друге.
- Пробелы — целый раздел приложения случайно остался без проверок.
- Хаос в отчётности — нельзя быстро понять, какой процент проверок прошёл успешно.
Правильно организованные тест-сьюты решают все эти проблемы.
3. Принципы группировки тест-кейсов
Существует несколько популярных способов группировки. Для начинающих самый удобный — по функциональности (по части приложения, которую вы проверяете).
Принцип 1: по функциональности
Самый распространённый. Все проверки одной функции — в одном тест-сьюте.
- Тест-сьют «Авторизация» → тест-кейсы про логин, пароль, «выйти из аккаунта»
- Тест-сьют «Оплата» → тест-кейсы про ввод карты, ошибки оплаты, чек
Принцип 2: по типу тестирования
- Тест-сьют «Позитивные сценарии» — проверяем, что всё работает при правильных действиях пользователя
- Тест-сьют «Негативные сценарии» — проверяем, что приложение корректно реагирует на ошибки пользователя
Позитивный сценарий — пользователь делает всё правильно (вводит верный пароль, нажимает нужные кнопки).
Негативный сценарий — пользователь ошибается или делает что-то нестандартное (вводит буквы в поле для цифр, оставляет поле пустым).
Принцип 3: по приоритету
- Тест-сьют «Критические проверки» (smoke-тесты) — самые важные, запускаем в первую очередь
- Тест-сьют «Детальные проверки» — более глубокие, запускаем после
Smoke-тест (буквально «дымовой тест») — это быстрый набор самых базовых проверок. Название пришло из электроники: прежде чем глубоко тестировать новое устройство, его просто включали и смотрели — нет ли дыма? Если устройство не задымилось — можно тестировать дальше.
В реальных командах часто комбинируют все три принципа.
4. Структура тест-сьюта
Хорошо оформленный тест-сьют содержит:
- Название — короткое, понятное, отражает тему (например, «TS-01: Авторизация»)
- Описание — одно-два предложения о том, что проверяется
- Список тест-кейсов — каждый с уникальным идентификатором (номером)
- Порядок выполнения — если важно, в какой последовательности запускать тесты
Идентификатор — это уникальный номер или код, который присваивается каждому тест-кейсу, чтобы на него можно было ссылаться: «смотри тест TC-005». Как инвентарный номер на мебели в офисе.
Типичное соглашение об именах:
TS(от Test Suite) — для тест-сьютов: TS-01, TS-02...TC(от Test Case) — для тест-кейсов: TC-001, TC-002...
5. Статусы тест-кейсов: как отмечать результат
После того как вы выполнили тест-кейс, нужно зафиксировать результат. Для этого используются статусы.
Статус — это пометка, которая говорит: «что получилось с этим тест-кейсом?».
Вот основные статусы, которые вы встретите в большинстве команд:
| Статус | Что означает | Аналогия |
|---|---|---|
| Pass (прошёл) | Всё работает так, как ожидалось | Блюдо приготовлено по рецепту — вкусно |
| Fail (провалился) | Нашли ошибку — результат не совпал с ожидаемым | Блюдо подгорело |
| Blocked (заблокирован) | Нельзя выполнить тест из-за другой ошибки | Нет электричества — плиту не включить |
| Skip (пропущен) | Тест намеренно не выполнялся (не успели, не актуально) | Рецепт отложили на следующий раз |
| In Progress (в работе) | Тест выполняется прямо сейчас | Блюдо готовится |
Важно: статус «Blocked» означает, что сам тест-кейс, скорее всего, написан верно, но запустить его не получается из-за другого дефекта. Например, если вы хотите проверить оплату, а сайт вообще не открывается — тест оплаты получит статус «Blocked».
6. Прогон тестов и тест-ран
Когда тестировщик берёт набор тест-кейсов и выполняет их один за другим — это называется тест-ран (от английского test run — прогон тестов).
Тест-ран — это один конкретный запуск тест-сьюта в определённый момент времени. Например: «Прогон тест-сьюта „Авторизация" 15 июня 2025 года, версия приложения 2.3.1».
Зачем отдельно фиксировать тест-ран? Потому что один и тот же тест-сьют можно запускать много раз: после каждого обновления приложения, после исправления ошибок. Каждый раз результаты будут разными — их нужно хранить отдельно, чтобы видеть динамику.
7. Простая таблица отслеживания результатов
Самый доступный инструмент для начинающего — обычная таблица в Excel, Google Sheets или даже в тетради.
Минимальный набор столбцов:
| ID | Название тест-кейса | Приоритет | Статус | Комментарий | Баг-репорт |
|---|---|---|---|---|---|
| TC-001 | Вход с верными данными | Высокий | Pass | — | — |
| TC-002 | Вход с неверным паролем | Высокий | Pass | — | — |
| TC-003 | Вход с пустым логином | Средний | Fail | Нет сообщения об ошибке | BR-012 |
| TC-004 | Восстановление пароля | Средний | Blocked | Кнопка не активна, BR-011 | BR-011 |
| TC-005 | Выход из аккаунта | Низкий | Skip | Не успели проверить | — |
Расшифровка столбцов:
- ID — уникальный номер тест-кейса
- Название — краткое описание, что проверяет тест
- Приоритет — насколько важен этот тест (Высокий / Средний / Низкий)
- Статус — результат выполнения (Pass / Fail / Blocked / Skip)
- Комментарий — краткая заметка, если статус не «Pass»
- Баг-репорт — ссылка на заведённую ошибку, если статус «Fail» или «Blocked»
8. Метрики: как считать прогресс
После заполнения таблицы можно посчитать простые числа, которые покажут, как идёт тестирование. Эти числа называются метриками (от слова «мера» — то, что можно измерить).
Самые базовые метрики:
Процент выполнения — сколько тест-кейсов уже запустили:
Выполнено / Всего × 100%
Пример: 4 / 5 × 100% = 80%
Процент успешных — сколько тестов прошли без ошибок:
Pass / Выполнено × 100%
Пример: 2 / 4 × 100% = 50%
Процент дефектов — сколько тестов выявили ошибку:
Fail / Выполнено × 100%
Пример: 1 / 4 × 100% = 25%
Эти три числа дают менеджеру и разработчику мгновенную картину: «Мы проверили 80% функций, из них половина работает нормально, четверть — с ошибками, один тест заблокирован».
9. Инструменты для организации тест-кейсов
На начальном уровне достаточно обычных таблиц. Но полезно знать, что профессиональные команды используют специальные программы — тест-менеджмент системы (системы управления тестированием).
Самые популярные:
| Инструмент | Особенность |
|---|---|
| TestRail | Профессиональный, платный, очень распространён |
| Zephyr | Встраивается в Jira (систему управления задачами) |
| Qase | Современный, есть бесплатный план |
| Allure TestOps | Популярен в русскоязычных командах |
| Google Sheets / Excel | Самый простой старт — без регистрации и настройки |
Для этого курса мы будем работать с Google Sheets и простыми текстовыми файлами — никаких лишних инструментов.
Пример: организуем тест-сьют для приложения «Заметки»
Допустим, мы тестируем простое мобильное приложение «Заметки». В нём можно:
- создавать заметки,
- редактировать их,
- удалять,
- искать по тексту.
Шаг 1. Определяем тест-сьюты
Мы разобьём тесты на три тест-сьюта по функциональности:
TS-01: Создание заметок
TS-02: Редактирование и удаление заметок
TS-03: Поиск заметок
Шаг 2. Наполняем тест-сьют тест-кейсами
Покажем тест-сьют TS-01: Создание заметок:
TS-01: Создание заметок
Описание: Проверяем, что пользователь может создавать новые заметки
в различных сценариях.
TC-001 Создание заметки с заголовком и текстом [Высокий]
TC-002 Создание заметки только с заголовком [Средний]
TC-003 Создание заметки только с текстом [Средний]
TC-004 Попытка создать пустую заметку [Средний]
TC-005 Создание заметки с очень длинным заголовком [Низкий]
Шаг 3. Проводим тест-ран и фиксируем результаты
После выполнения тестов заполняем таблицу:
Тест-ран: TS-01 / Дата: 20.06.2025 / Версия приложения: 1.0.0
ID | Название | Приоритет | Статус | Комментарий | Баг
--------|-------------------------------------------|-----------|----------|------------------------------------|--------
TC-001 | Создание заметки с заголовком и текстом | Высокий | Pass | — | —
TC-002 | Создание заметки только с заголовком | Средний | Pass | — | —
TC-003 | Создание заметки только с текстом | Средний | Fail | Заметка сохраняется без заголовка, | BR-001
| | | | но заголовок отображается пустым — |
| | | | ожидалось «Без названия» |
TC-004 | Попытка создать пустую заметку | Средний | Pass | — | —
TC-005 | Заметка с очень длинным заголовком | Низкий | Fail | Заголовок обрезается без | BR-002
| | | | предупреждения пользователя |
Шаг 4. Считаем метрики
Всего тест-кейсов: 5
Выполнено: 5 → 5/5 × 100% = 100%
Pass: 3 → 3/5 × 100% = 60%
Fail: 2 → 2/5 × 100% = 40%
Blocked: 0
Skip: 0
Вывод: тест-сьют TS-01 полностью пройден.
Найдено 2 дефекта, оба некритичные.
Основная функция (TC-001) работает корректно.
Итоговая структура в виде иерархии
Проект: Приложение «Заметки»
│
├── TS-01: Создание заметок
│ ├── TC-001: Создание с заголовком и текстом
│ ├── TC-002: Только с заголовком
│ ├── TC-003: Только с текстом
│ ├── TC-004: Пустая заметка
│ └── TC-005: Очень длинный заголовок
│
├── TS-02: Редактирование и удаление
│ ├── TC-006: Редактирование заголовка
│ ├── TC-007: Редактирование текста
│ ├── TC-008: Удаление заметки
│ └── TC-009: Отмена удаления
│
└── TS-03: Поиск заметок
├── TC-010: Поиск по ключевому слову
├── TC-011: Поиск без результатов
└── TC-012: Поиск с пустой строкой
Такая иерархия сразу показывает полный охват: три тест-сьюта, двенадцать тест-кейсов — ничего не потеряно.
Практика
Упражнение 1. Разбейте тест-кейсы на тест-сьюты
Перед вами список тест-кейсов для приложения по заказу еды. Сгруппируйте их в логичные тест-сьюты и дайте каждому тест-сьюту название.
Список тест-кейсов:
- Открытие карточки ресторана
- Регистрация нового пользователя
- Добавление блюда в корзину
- Вход с верными логином и паролем
- Оплата заказа картой
- Поиск ресторана по названию
- Удаление блюда из корзины
- Вход с неверным паролем
- Применение промокода
- Фильтрация ресторанов по кухне
- Просмотр истории заказов
- Изменение адреса доставки в профиле
Подсказка: выделите 4–5 тест-сьютов. Например, «Авторизация», «Каталог», «Корзина», «Оплата», «Профиль».
Упражнение 2. Заполните таблицу результатов
Вы провели тест-ран для тест-сьюта «Авторизация» и получили следующие результаты:
- TC-001 «Регистрация с валидными данными» — всё сработало нормально.
- TC-002 «Вход с верным паролем» — всё сработало нормально.
- TC-003 «Вход с неверным паролем» — система приняла неверный пароль и пустила в аккаунт. Это явная ошибка.
- TC-004 «Восстановление пароля через email» — кнопка «Отправить письмо» не активна. Причина неизвестна — скорее всего, другой баг блокирует эту функцию.
- TC-005 «Выход из аккаунта» — вы не успели проверить, время вышло.
Создайте таблицу (можно нарисовать в тетради или в Google Sheets) со столбцами: ID, Название, Статус, Комментарий. Заполните её по описанным результатам.
Подсказка: определите правильный статус для каждого тест-кейса из списка: Pass, Fail, Blocked, Skip.
Упражнение 3. Посчитайте метрики
На основе таблицы из Упражнения 2 вычислите:
- Процент выполненных тест-кейсов (тех, которые запустили).
- Процент тест-кейсов со статусом Pass от всех выполненных.
- Процент тест-кейсов со статусом Fail от всех выполненных.
Запишите выводы одним-двумя предложениями: что можно сказать о качестве приложения на основе этих чисел?
Упражнение 4. Составьте тест-сьют с нуля
Представьте, что вы тестируете функцию «Смена пароля» в любом знакомом вам приложении (соцсеть, банковское приложение, почта — на ваш выбор).
- Придумайте название тест-сьюта и дайте ему идентификатор (например, TS-04).
- Напишите 5–7 тест-кейсов для этой функции. Для каждого укажите ID, название и приоритет (Высокий / Средний / Низкий).
- Подумайте: какой тест-кейс вы бы проверили первым и почему?
Подсказка: вспомните позитивные и негативные сценарии. Что будет, если ввести правильные данные? А если ввести слишком короткий пароль? А если новый пароль совпадает со старым?
Ключевые выводы
- Тест-сьют — это папка с тест-кейсами, объединёнными общей темой (функцией, разделом приложения или типом проверки).
- Группировка тест-кейсов помогает избежать потерь, дублирования и пробелов в покрытии.
- Самый популярный принцип группировки — по функциональности: один тест-сьют = одна функция или раздел приложения.
- Каждый выполненный тест-кейс получает статус: Pass, Fail, Blocked, Skip или In Progress.
- Тест-ран — это один конкретный запуск тест-сьюта в определённое время и для определённой версии приложения.
- Результаты удобно фиксировать в таблице с колонками: ID, название, приоритет, статус, комментарий, ссылка на баг.
- Простые метрики (процент выполненных, процент Pass, процент Fail) дают быстрое понимание состояния качества продукта.
- Начинать можно с Google Sheets или обычной таблицы — профессиональные инструменты вроде TestRail или Qase делают то же самое, но с большим удобством для больших команд.