Тестовая документация
🧾 Зачем вообще нужна тестовая документация
В работе тестировщика ≈ 25% времени уходит не на «тыкание» в интерфейсе, а на:
- составление чек-листов 📝
- написание тест-кейсов
- оформление баг-репортов 🐞
- участие в тест-планах и других документах
- на собесах (очень любят спрашивать),
- в реальной работе (без документации команда быстро утонет в хаосе).
1. Чек-лист ✅
💡 Определение
Чек-лист — это упорядоченный список пунктов (проверок), которые нужно выполнить во время тестирования.
«Что нужно проверить, чтобы ничего не забыть?»
Это не пошаговая инструкция, а список того, что должно быть проверено.
🎯 Зачем нужен чек-лист
- помогает ничего не забыть;
- снижает риск пропустить важный баг;
- позволяет быстро пробежаться по основным функциям;
- хорош как план тестирования на задачу/фичу.
✏️ Пример чек-листа для формы регистрации
- Поля «Имя», «Email», «Пароль» — обязательные
- Неверный email обрабатывается (показывается ошибка)
- Проверка минимальной и максимальной длины пароля
- Проверка поля «Подтверждение пароля»
- Кнопка «Зарегистрироваться» активна с валидными данными
- Ошибки при незаполненных полях отображаются
- Успешная регистрация с валидными данными
- Отправляется подтверждающее письмо на email
👀 Пример чек-листа из реального проекта (чуть упрощённо)
- На вкладке «Отправленные SMS» вообще есть такая вкладка
- Если есть отправленные SMS — они отображаются
- В блоке «Количество SMS» показывается количество, с разбивкой по статусам
- В блоке «Список отправленных SMS» есть детализация (кому, когда, статус и т.п.)
- Поиск работает корректно
- В поле поиска можно вставлять текст
- Сортировка по дате работает, граничные значения учитываются
- Отображаются номера, которые уперлись в лимит
- Для каждой записи видны: номер телефона, сервис, количество попыток, дата снятия ограничения, состояние «сброс»
- Кнопка «Сбросить лимит» работает корректно
🧪 Практика (твоё упражнение)
Задание:
Выбери любой предмет из своей комнаты (например: кружка, стул, телефон, лампа) и составь чек-лист из 7 проверок для этого предмета.
Можно использовать:функциональные проверки (что он делает),нефункциональные (удобно ли, красиво ли, устойчиво ли и т.д.).
2. Тест-кейс 🧩
💡 Простое определение
Тест-кейс — это подробный сценарий проверки какого-то одного конкретного кусочка функционала.
Это уже не просто список пунктов, а пошаговая инструкция.
💡 Формальное определение (чуть серьёзнее)
Тест-кейс — набор:входных данных,предусловий,шагов выполнения,ожидаемых результатов и постусловий,
созданный для проверки определённого требования или сценария.
🧱 Обязательные атрибуты тест-кейса
То, без чего нормальный тест-кейс жить не может:
- 🆔 Уникальный идентификатор
Номер тест-кейса (например,TC-REG-001). - 🏷 Название
Кратко и понятно:
«Регистрация с валидными данными» - ⚙️ Предусловия (Preconditions)
Что должно быть выполнено до начала шагов, например: - 👣 Шаги
Последовательность действий. Каждый шаг — это действие, а не наблюдение: - 🎯 Ожидаемый результат
Что именно мы должны увидеть после выполнения шагов:
Дополнительно (желательно, но не строго обязательно):
✅ Результаты выполнения тест-кейса
Когда мы выполнили тест-кейс, он может дать один из трёх статусов:
- Положительный (Passed)
Фактический результат = ожидаемому. Всё хорошо. - Отрицательный (Failed)
Фактический ≠ ожидаемому. Нашли баг. - Блокирован (Blocked)
Невозможно продолжать, потому что что-то сломалось раньше (тоже баг, но блокирующий тест).
❌ Чего не должно быть в тест-кейсе
- Зависимостей от других тест-кейсов
Тест должен быть максимально самодостаточным. - Нечётких формулировок
Типа: «проверить, что всё нормально».
Надо конкретно: «отображается сообщение "Успешно сохранено"». - Отсутствия важной информации
Нельзя написать «проверить логин» и не указать логин и пароль (или ссылку на источник этих данных). - Излишней детализации
Не нужно писать «нажать цифру 1 на клавиатуре, затем 2» — достаточно «ввести значение 12».
🧪 Пример тест-кейса (упрощённый)
Название: Регистрация пользователя с валидными данными
Предусловия: Пользователь не зарегистрирован в системе
- Открыть страницу регистрации
- Ввести в поле «Имя» —
Иван Иванов - Ввести в поле «Email» —
ivan.ivanov@example.com - Ввести в поле «Пароль» —
Password123 - Повторить пароль в поле «Подтверждение пароля»
- Нажать кнопку «Зарегистрироваться»
- Пользователь успешно зарегистрирован
- Отображается сообщение «Проверьте вашу почту»
- На email отправлено письмо с подтверждением
🧮 Уровни детализации тест-кейсов
- Верхнеуровневые — общие, без суперподробностей«Зарегистрировать пользователя с валидными данными»
- Низкоуровневые — очень детальныекаждый шаг расписан, как для человека, который впервые видит систему.
Ты сам/а будешь подбирать уровень детализации под:
🛠 Инструменты
🧪 Практика (твоё упражнение)
Задание:
Составь тест-кейс на проверку любой функциональности интернет-магазина:авторизация,добавление товара в корзину,оформление заказа,поиск товара и т.д.Оформи:в таблице,в документе,или в TMS (например, Qase).Потом приложи файл или скрин.
3. Тест-план 📋
Тест-план — это уже не один сценарий, а стратегический документ, который описывает:
- что именно мы будем тестировать (объект тестирования),
- стратегию и подходы (как будем тестировать),
- график тестирования,
- критерии «начать» и «закончить» тестирование,
- какие ресурсы и окружение нужны,
- какие есть риски и что будем делать, если они проявятся.
Обычно тест-план делают лиды / сеньоры, но джуну полезно понимать, что это такое.
4. Баг-репорт 🐞
💡 Определение
Баг-репорт — это официальное описание найденной ошибки, которое помогает:
- разработчику понять, что именно сломалось,
- как воспроизвести проблему,
- насколько она серьёзна и важна.
Хороший баг-репорт отвечает на два главных пункта:
🧱 Обязательные поля баг-репорта
Общая структура (конкретные поля зависят от баг-трекера, но суть такая):
- 🏷 Заголовок (Title)
- 📋 Описание / Шаги воспроизведения (Steps to Reproduce)
- 🎯 Фактический результат (Actual result)
- ✅ Ожидаемый результат (Expected result)
- 💣 Severity (серьёзность)
- 🚦 Priority (приоритет)
- 💻 Environment (окружение)
- 📎 Вложения (Attachments)
🔍 Название баг-репорта: «Что? Где? Когда?»
Хорошее название должно отвечать на 3 вопроса:
- Что? — что сломалось и как именно?«Картинка с котиком уезжает за пределы экрана»
- Где? — где именно проблема? (страница, модуль, компонент)«…на главной странице»
- Когда? — при каких условиях/действиях это происходит?«…при ширине окна браузера менее 500px»
«Картинка с котиком на главной странице уезжает за границу экрана при ширине окна < 500px»
🎚 Серьёзность багов (Severity)
Severity — это насколько сильно баг ломает систему с технической точки зрения.
- 🟥 Critical / Blocker — ничего не работает: система падает, невозможно зайти, оформить заказ и т.д.
- 🔴 Major / High — важная функциональность ломается, но система не падает полностью.
- 🟠 Medium — заметно, мешает, но можно жить.
- 🟢 Minor / Low — мелочь: опечатка, пиксель влево, цвет не тот.
🚦 Приоритет багов (Priority)
Priority — это насколько срочно нужно чинить баг для бизнеса.
Иногда баг технически не страшный, но очень важный для бизнеса (например, опечатка в цене на главном баннере).
🔁 Примеры комбинаций: Severity vs Priority
🔼 Высокий приоритет, низкая серьёзность
- Важный лендинг, на главной кнопке вместо «Купить» написано «Купипь».
- Функционально всё работает, система не ломается, но
Severity — Low (опечатка)
Priority — High (чинить быстро).
🔼 Высокая серьёзность, низкий приоритет
- В старом разделе отчётов, которым никто не пользуется,
- при очень специфическом наборе фильтров
- система падает с ошибкой.
Технически: серьёзно, падение.
Но бизнес говорит: «Этот отчёт будет удалён через месяц, никто им не пользуется».
Severity — High / Critical
Priority — Low
🧪 Практика (твоё упражнение)
Задание:
Найди 3 бага на любом сайте (можно учебный проект, демо-сайт, даже формочки простые) и:Оформи 3 баг-репортаВ любом виде: таблица, текстовый документОбязательно укажи:заголовок (с «что/где/когда»),шаги,ожидаемый результат,фактический результат,severity и priority.
5. Скриншоты и Lightshot 📸
В баг-репортах очень полезно прикладывать:
Для работы со скриншотами удобно:
👉 Lightshot — https://app.prntscr.com/ru/index.html
Если баг визуальный (верстка, отступы, вылезла картинка) — скриншот почти обязателен.
Хорошо, если на скрине ты подсветишь место ошибки стрелочкой или рамкой.
6. Частые ошибки в тестовой документации 🚫
Особенно при написании тест-кейсов и баг-репортов.
1️⃣ Ошмётки ожидаемого результата в шагах
Шаг 2: Нажать на кнопку "HERE" в строчке для перехода на следующую страницу
Здесь в шаг шагами уже залезла часть «что произойдёт».
Шаг 2: Нажать на кнопку «HERE»
Ожидаемый результат: Переход на страницу регистрации
2️⃣ Ошмётки шагов в ожидаемом результате
Ожидаемый результат: При нажатии на кнопку Sign In происходит переход на страницу авторизации
Мы уже написали «нажать кнопку» в шагах.
Шаг 3: Нажать на кнопку Sign In
Ожидаемый результат: Происходит переход на страницу авторизации
3️⃣ Несколько багов в одном баг-репорте
«Зелёная кнопка на главной странице имеет текст "No" и её нажатие не приводит к переходу на страницу Х»
✅ Лучше сделать два отдельных баг-репорта:
- «Текст "No" на зелёной кнопке на главной странице»
- «При нажатии зелёной кнопки на главной странице не происходит переход на страницу Х»
- один пофиксят, второй забудут;
- у багов может быть разный приоритет;
- так ты показываешь больше собственной работы 😏