Тестовая документация нужна, чтобы проверки были повторяемыми, передаваемыми и прозрачными для команды. Но документация ради документации вредна: её надо писать столько, сколько окупается.
Чек-лист
Список проверок без подробных шагов:
Форма входа
- вход с верными email и паролем
- email в другом регистре
- неверный пароль: общее сообщение «неверный логин или пароль»
- пустой email, пустой пароль (по отдельности)
- пароль скрыт точками, есть кнопка показа
- Enter отправляет форму
- после 5 неудачных попыток капча
Плюсы: быстро писать, легко поддерживать, гибко выполнять. Минус: выполнение зависит от знаний человека.
Тест-кейс
Подробное описание одной проверки:
ID: LOGIN-004
Название: Вход с неверным паролем показывает общее сообщение
Предусловия: существует пользователь user1@test.ru с паролем Qwerty123
Шаги: 1. Открыть /login
2. Ввести email user1@test.ru
3. Ввести пароль wrong123
4. Нажать «Войти»
Ожидаемый: сообщение «Неверный логин или пароль»,
пользователь остаётся на странице входа
Постусловия: нет
Правила хорошего тест-кейса:
- Атомарный: одна главная проверка. Если тест «регистрация, вход, смена пароля, выход» упадёт на втором шаге, остальное не проверено, а причина неясна.
- Проверяемый ожидаемый результат: что конкретно видно. «Всё работает корректно» не результат.
- Воспроизводимый: конкретные данные в шагах или предусловиях.
- Независимый от других тест-кейсов, насколько возможно.
Когда что
| Ситуация | Что писать |
|---|---|
| Регулируемая отрасль, нужен след проверки | Тест-кейсы |
| Тестирование передают новичкам или подрядчику | Тест-кейсы |
| Основа для автоматизации | Тест-кейсы или сценарии BDD |
| Быстро меняющийся продукт, опытная команда | Чек-листы |
| Новая функциональность без документации | Чартеры исследовательского тестирования |
Формат BDD
Сценарий в формате Gherkin: Given (Дано) исходное состояние, When (Когда) действие, Then (Тогда) результат.
Сценарий: Промокод уменьшает сумму
Дано пользователь с товаром за 3000 ₽ в корзине
Когда он применяет промокод SALE10
Тогда итог корзины 2700 ₽
Такие сценарии читают и аналитики, и тестировщики, а инструменты вроде Cucumber превращают их в автотесты.
Тест-план и тест-стратегия
Тест-стратегия общая и долгоживущая: какие уровни тестирования, что автоматизируем, какие инструменты, как управляем дефектами, какие окружения.
Тест-план конкретный, на проект или релиз:
- объём: что тестируем и что не тестируем;
- подходы и виды тестирования;
- окружения и тестовые данные;
- ресурсы, роли, график;
- риски и меры;
- критерии входа, выхода, приостановки.
Шаги тест-кейсов в план не входят, они живут в системе управления тестами (TestRail, Qase, Allure TestOps, Zephyr и подобные).
Матрица трассируемости
Таблица связей «требование → тесты → результаты → дефекты». Пустая строка значит непокрытое требование. При изменении требования сразу видно, какие тесты обновить.
Тестовые данные
Данные описывают в предусловиях и умеют восстанавливать: скрипты, фикстуры, сиды. Копию прода без обезличивания на стенд не тянут: это нарушение закона о персональных данных и риск утечки.
Приоритет и ревизия
Тест-кейсы приоритизируют по риску: вероятность дефекта × ущерб. Регулярно чистят: устаревшие удаляют или архивируют, мелкие сворачивают в чек-листы, по каждому утёкшему в прод багу добавляют проверку.
Отчёт о тестировании
Коротко и для тех, кто принимает решение: что проверено и что нет, результаты, открытые дефекты по серьёзности, отклонения от плана, остаточные риски, рекомендация.
Что спросят на собесе
- Чем тест-кейс отличается от чек-листа? Когда что лучше?
- Из чего состоит тест-кейс? Каким должен быть ожидаемый результат?
- Что входит в тест-план? Чем он отличается от стратегии?
- Зачем нужна матрица трассируемости?
- Составь чек-лист для формы входа.