Что такое тестовая документация и зачем её писать

Вступление: зачем вообще что-то записывать?

Представьте, что вы купили новый холодильник. Вы включили его, положили продукты и ушли. Через неделю сосед говорит: «Слушай, у тебя молоко не испортилось? У меня такая же модель — не морозит». Вы хотите проверить, правильно ли работает ваш холодильник. Но что именно проверять? При какой температуре? Как долго? Что считать «правильной работой», а что — поломкой?

Без ответов на эти вопросы вы будете проверять наугад. Может, что-то найдёте, а может — пропустите важное.

В тестировании программного обеспечения та же история. Когда тестировщик проверяет приложение без записей, он рискует:

• забыть, что уже проверял;
• проверять одно и то же по два раза;
• пропустить важный сценарий;
• не суметь объяснить коллеге или руководителю, что именно было проверено.

Тестовая документация — это любые записи, которые помогают планировать, проводить и отслеживать тестирование. Это не бюрократия ради бюрократии, а инструмент, который делает работу предсказуемой и понятной всем участникам команды.

Теория

Шаг 1. Что такое тестовая документация — простыми словами

Тестовая документация (test documentation) — это набор документов, которые описывают: что нужно проверить, как это сделать, какой результат ожидается и что получилось на самом деле.

Аналогия из жизни: представьте повара в ресторане. У него есть рецепт (что и как готовить), чеклист перед открытием (проверить все ли продукты свежие) и журнал жалоб (что гости говорили о блюдах). Всё это — документация. Без неё каждый повар готовил бы по-своему, а менеджер не знал бы, почему одно и то же блюдо каждый раз выходит разным.

Шаг 2. Основные виды тестовой документации

Разберём самые важные документы, с которыми работает тестировщик.

2.1 Тест-кейс (Test Case)

Тест-кейс — это подробная инструкция для проверки одной конкретной функции или поведения программы. Он отвечает на вопрос: «Если я сделаю вот это — что должно произойти?»

Тест-кейс похож на инструкцию по проверке бытового прибора:

«Нажмите кнопку "Вкл". → Должен загореться зелёный индикатор и начать работать мотор.»

Структура типичного тест-кейса:

💡 Важное понятие — «ожидаемый результат»: это не то, что вы хотите увидеть, а то, что должно произойти согласно требованиям или здравому смыслу. Если кнопка «Удалить» удаляет запись — это ожидаемый результат. Если она удаляет весь аккаунт — это скорее всего баг.

2.2 Чеклист (Checklist)

Чеклист — это упрощённый список того, что нужно проверить, без подробных шагов. Представьте список покупок в магазине: там написано «молоко», а не «подойди к холодильнику, возьми пакет, проверь срок годности».

Чеклист удобен, когда:

• нет времени писать подробные тест-кейсы;
• тестировщик хорошо знает систему и понимает, как именно проверять;
• нужно быстро пробежаться по основным функциям.

Пример чеклиста для проверки формы регистрации:

[ ] Форма открывается без ошибок
[ ] Поле «Email» принимает корректный адрес
[ ] Поле «Email» не принимает текст без символа @
[ ] Поле «Пароль» скрывает введённые символы
[ ] Кнопка «Зарегистрироваться» активна только когда все поля заполнены
[ ] После успешной регистрации пользователь получает письмо на email
[ ] При повторной регистрации с тем же email появляется сообщение об ошибке

💡 Разница между тест-кейсом и чеклистом: тест-кейс — это подробный рецепт с точными шагами, чеклист — это список блюд, которые нужно приготовить. Тест-кейс занимает больше времени на написание, но оставляет меньше простора для интерпретации. Чеклист пишется быстро, но требует от тестировщика больше самостоятельного мышления.

2.3 Баг-репорт (Bug Report)

Баг-репорт — это документ, который описывает найденную ошибку в программе. Слово баг (bug) означает ошибку или дефект: что-то работает не так, как должно.

Баг-репорт — это не жалоба и не донос на разработчика. Это точное, нейтральное описание проблемы, которое помогает разработчику понять: что сломалось, при каких условиях, и насколько это критично.

Представьте, что вы звоните в службу поддержки сотового оператора. Вы скажете: «У меня не работает интернет» — и оператор начнёт задавать уточняющие вопросы. А если вы скажете: «У меня телефон iPhone 13, iOS 16.4, тариф "Безлимит", вчера после 18:00 перестал работать мобильный интернет — показывает значок 4G, но страницы не загружаются» — оператор сразу понимает, с чего начать.

Структура баг-репорта:

💡 Severity vs Priority — в чём разница?

• Severity (серьёзность) — техническое влияние на продукт. Например, «приложение падает при нажатии на кнопку» — это критическая серьёзность.
• Priority (приоритет) — бизнес-важность. Например, опечатка в названии компании на главной странице — низкая серьёзность, но высокий приоритет (потому что это видят все пользователи и это репутационный ущерб).

2.4 Тест-план (Test Plan)

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

Если тест-кейсы — это рецепты отдельных блюд, то тест-план — это меню всего ресторана на сезон: какие блюда войдут в меню, кто будет готовить, когда откроемся, сколько потратим.

Тест-план обычно пишет опытный тестировщик или тест-лид. Начинающему специалисту важно понимать его структуру, чтобы уметь работать по нему.

Разделы типичного тест-плана:

• Цель тестирования — что именно хотим проверить и почему
• Область тестирования (Scope) — что входит в тестирование, а что — нет
• Виды тестирования — функциональное, нагрузочное, и т.д.
• Ресурсы — кто тестирует, на каком оборудовании
• Риски — что может пойти не так
• Критерии завершения — когда можно считать тестирование выполненным

2.5 Тест-сьют (Test Suite)

Тест-сьют (Test Suite) — это коллекция (группа) тест-кейсов, объединённых по какому-то признаку. Например, все тест-кейсы для проверки авторизации — один тест-сьют, все тест-кейсы для проверки оплаты — другой.

Аналогия: если тест-кейс — это отдельная карточка с рецептом, то тест-сьют — это папка с рецептами на одну тему (например, «Салаты» или «Десерты»).

Шаг 3. Зачем всё это нужно — 5 причин

1. Повторяемость. Любой тестировщик может взять ваши тест-кейсы и провести ровно те же проверки, что и вы. Это важно при смене сотрудников или при регрессионном тестировании (проверке того, что старые функции не сломались после новых изменений).

2. Прозрачность. Менеджер проекта видит: вот 150 тест-кейсов, 140 — пройдены, 10 — провалены. Он понимает, насколько готов продукт.

3. Доказательная база. Если клиент говорит «вы не проверили вот эту функцию», у вас есть документы, которые подтверждают обратное.

4. Накопление знаний. Если вы уволитесь, ваш опыт останется в документах. Новый сотрудник не начнёт с нуля.

5. Основа для автоматизации. Хорошо написанные тест-кейсы — это будущие автоматические тесты. Чем чётче описаны шаги, тем легче их автоматизировать.

Шаг 4. Принципы хорошей тестовой документации

Запомните несколько правил, которые сделают ваши документы полезными, а не формальными:

Правило 1: Один тест-кейс — одна проверка.
Не пытайтесь в одном тест-кейсе проверить и авторизацию, и оплату, и выход из аккаунта. Если тест провалился в середине, непонятно, что именно не работает.

Правило 2: Шаги должны быть конкретными.
Плохо: «Войдите в систему и что-нибудь купите».
Хорошо: «1. Откройте страницу example.com/login. 2. Введите в поле "Email" значение [email protected]. 3. ...»

Правило 3: Ожидаемый результат — не процесс, а итог.
Плохо: «Система обрабатывает запрос».
Хорошо: «Появляется сообщение "Заказ оформлен №12345" и пользователь получает письмо на почту».

Правило 4: Пишите для незнакомца.
Представьте, что ваши тест-кейсы будет читать человек, который впервые видит эту программу. Ему должно быть понятно без дополнительных объяснений.

Правило 5: Обновляйте документы.
Если программа изменилась, тест-кейсы должны отражать это. Устаревшая документация хуже, чем её отсутствие — она вводит в заблуждение.

Пример: пишем тест-кейс с нуля

Допустим, мы тестируем простое мобильное приложение для заметок. Нам нужно проверить функцию создания новой заметки.

Сначала задаём себе вопросы:

• Что пользователь делает, чтобы создать заметку?
• Что должно произойти после сохранения?
• Что считать ошибкой?

Пишем тест-кейс:

## Тест-кейс TC-007

**Название:** Создание новой заметки с заголовком и текстом

**Предусловие:**
- Приложение установлено и открыто
- Пользователь находится на главном экране со списком заметок

**Шаги:**
1. Нажать кнопку «+» (добавить заметку) в правом нижнем углу экрана
2. В поле «Заголовок» ввести текст: «Список покупок»
3. В поле «Текст заметки» ввести: «Молоко, хлеб, яблоки»
4. Нажать кнопку «Сохранить»

**Ожидаемый результат:**
- Приложение возвращает пользователя на главный экран
- В списке заметок появляется новая заметка с заголовком «Список покупок»
- Заметка отображает первую строку текста: «Молоко, хлеб, яблоки»
- Заметка показывает текущую дату создания

**Фактический результат:** _(заполняется после выполнения теста)_

**Статус:** _(Пройден / Провален / Заблокирован)_

**Приоритет:** Высокий

**Примечания:** Проверить также на iOS и Android

А если тест провалился — пишем баг-репорт:

## Баг-репорт BUG-023

**Заголовок:** Новая заметка не появляется в списке после сохранения

**Окружение:**
- Устройство: Samsung Galaxy A53
- ОС: Android 13
- Версия приложения: 2.4.1

**Шаги воспроизведения:**
1. Открыть приложение «Заметки»
2. Нажать кнопку «+»
3. Ввести заголовок «Список покупок» и текст «Молоко, хлеб, яблоки»
4. Нажать «Сохранить»

**Ожидаемый результат:**
Новая заметка «Список покупок» появляется в общем списке заметок

**Фактический результат:**
Приложение возвращает на главный экран, но новая заметка в списке не отображается.
После перезапуска приложения заметка появляется.

**Серьёзность (Severity):** Средняя (Major)
**Приоритет (Priority):** Высокий

**Вложения:** [скриншот_главного_экрана.png], [запись_экрана.mp4]

💡 Обратите внимание: в баг-репорте мы написали не «приложение сломано», а точно описали: что сделали, что ожидали, что получили и при каких условиях это воспроизводится. Разработчик может сразу приступить к исправлению, не задавая дополнительных вопросов.

Практика

Выполните следующие задания самостоятельно. Для них не нужен компьютер с установленным ПО — достаточно текстового редактора (например, блокнота или Google Docs).

Задание 1. Найдите ошибки в тест-кейсе

Ниже написан тест-кейс. В нём несколько проблем. Найдите их и напишите, как бы вы их исправили.

Тест-кейс: Проверка входа

Шаги:
1. Откройте сайт
2. Как-нибудь войдите в аккаунт
3. Проверьте, что всё работает

Ожидаемый результат:
Система обрабатывает запрос и реагирует

Подсказка: Перечитайте «Принципы хорошей тестовой документации» выше и сравните с тем, что написано.

Задание 2. Напишите свой чеклист

Возьмите любое приложение, которым вы пользуетесь каждый день (мессенджер, приложение банка, почта, социальная сеть). Выберите одну функцию, например «отправка сообщения» или «перевод денег».

Составьте чеклист из 6–10 пунктов для проверки этой функции. Используйте формат:

[ ] Пункт проверки

Не нужно быть правым или неправым — главное, думать как пользователь и как человек, который хочет найти проблему.

Задание 3. Напишите тест-кейс

Представьте, что вы тестируете форму входа на сайте. Напишите тест-кейс для следующего сценария:

Сценарий: Пользователь пытается войти с неправильным паролем.

Используйте структуру из урока: ID, название, предусловие, шаги, ожидаемый результат. Поле «фактический результат» оставьте пустым.

Задание 4. Попрактикуйтесь в составлении баг-репорта

Вспомните любую ситуацию из жизни, когда что-то не работало так, как должно: сайт показал ошибку, приложение зависло, кнопка не нажималась. Опишите эту ситуацию в формате баг-репорта, используя структуру из урока.

Если реального примера нет — придумайте: например, «кнопка "Отправить" в форме обратной связи не реагирует на нажатие».

Ключевые выводы

• Тестовая документация — это инструмент, а не бюрократия. Она делает тестирование предсказуемым, повторяемым и понятным для всей команды.
• Тест-кейс описывает одну конкретную проверку: шаги, предусловие и ожидаемый результат. Один тест-кейс — одна проверка.
• Чеклист — это быстрый список того, что нужно проверить, без подробных шагов. Удобен, но требует опыта от исполнителя.
• Баг-репорт — это нейтральное, точное описание найденной ошибки. Хороший баг-репорт позволяет разработчику воспроизвести проблему без дополнительных вопросов.
• Тест-план описывает стратегию всего тестирования: что, кто, когда и как будет проверяться.
• Тест-сьют — это группа тест-кейсов, объединённых по теме или функциональности.
• Ожидаемый результат — это не то, что вы хотите увидеть, а то, что должно произойти согласно требованиям.
• Хорошая документация пишется так, чтобы незнакомый человек мог выполнить тест без дополнительных объяснений.
• Документацию нужно обновлять при каждом изменении продукта — устаревшие тест-кейсы хуже, чем их отсутствие.