Как написать ТЗ на тестирование, чтобы его прочитали разработчики

29 марта 2026 г. 19K

ТЗ на тестирование — документ, который чаще всего пишется впустую. QA-инженер тратит два дня на формализацию, разработчики не открывают ссылку, через неделю начинаются фразы «у нас же это не было в требованиях». В большинстве команд test plan превращается в галочку на онбординг и пылится в Confluence.

Есть способ писать ТЗ так, чтобы их читали и использовали. За семь лет в QA я перепробовала классические шаблоны IEEE 829, гибкие one-pager-ы, чек-листы в Notion и таблицы в Google Sheets. Расскажу, что взлетело — и почему «классический» test plan здесь чаще всего проигрывает.

Почему ТЗ не читают

Главная причина — оно написано не для разработчика, а для самого QA-инженера или менеджера. Длинные главы про «cтратегию тестирования», «риски», «entry/exit criteria» нужны на проектах с ISO-аудитом и в банках с регуляторкой. На обычной команде это белый шум.

Разработчику нужны три вещи, и в таком порядке:

Что именно проверяется и какие сценарии считаются «работает».
Какие негативные кейсы я должен покрыть со своей стороны (юнит, интеграция).
Где границы — что НЕ проверяется и почему.

Если этих трёх пунктов в документе нет, разработчик закрывает вкладку и идёт писать код. Все остальные разделы — для QA-руководителя и для аудита.

Структура one-pager

Базовый шаблон, который зашёл в трёх командах подряд:

1. Контекст (3–5 строк)

Что делаем, на каком тикете, какая фича. Без перепева user story — на неё ссылка одной строкой.

**Фича:** Сохранение черновика статьи  
**Тикет:** PROJ-1234  
**User story:** Автор может сохранить недописанную статью и вернуться к ней позже  
**Стенд:** staging.example.com / api.staging.example.com

2. Что проверяем (главные сценарии)

Список сценариев в формате Given-When-Then или просто пунктами. Не стесняюсь формулировок «нажал кнопку — увидел тост». Цель — общий язык с разработчиком, не парад терминологии.

### Главные сценарии
1. Автор пишет 100 символов в редакторе → черновик автоматически сохраняется через 5 секунд
2. Автор обновляет страницу → текст подгружается из черновика
3. Автор удаляет черновик кнопкой "Удалить черновик" → редактор пустой, локально и на сервере
4. Автор начинает новый пост → старый черновик сохраняется отдельной записью

3. Что точно проверим автоматизированно

Список конкретных тестов, которые я (QA) напишу: уровень (unit / api / e2e), стек, ориентировочное количество.

### Автотесты
- API (pytest+httpx, ~6 тестов): создание черновика, обновление, удаление, лимиты, авторизация
- E2E (Playwright, ~3 теста): автосохранение, восстановление после reload, удаление
- Visual regression — не делаем, UI без значимых изменений

4. Что просим у разработчиков

Список юнит/интеграционных проверок, которые ожидаются на стороне разработки. Это снимает повторение покрытия и показывает разделение ответственности.

### Зона разработки
- Unit на DraftService.merge() — все варианты конфликта (новый клиента, старый сервера)
- Unit на debounce-логику автосейва (5s после последнего ввода)
- Интеграционный тест: при race-condition (два таба одного автора) выживает последний по timestamp

5. Что НЕ проверяем

Самый важный раздел и самый редко пишущийся. Здесь — границы. Если завтра PM скажет «а это разве не в скоупе тестирования», ты ткнёшь в этот раздел.

### Вне скоупа
- Не проверяем работу при отключённой сети (это отдельная фича PROJ-2001)
- Не нагрузочное тестирование автосейва — текущий профиль не предполагает 1000+ rps на ручку
- Не оффлайн-сохранение в localStorage — фича не реализована

6. Риски и допущения

Короткий список рисков, которые могут сорвать релиз. Без длинных абзацев. Если риск тянет на отдельный документ — пиши его, на ссылку в ТЗ.

### Риски
- Риск конфликтов при работе из двух вкладок одновременно — закрывается логикой last-write-wins
- Риск переполнения хранилища черновиков — лимит 50 на пользователя, проверяется на API-уровне

Этот документ помещается на одной странице A4. Открывается за 30 секунд, читается за 2 минуты. На вопрос «зачем такой короткий, где детали?» — детали в тестах, в коде, в тикете. ТЗ — это карта, не территория.

Где жить документу

Класть в Confluence — гарантированно потерять. Confluence — это могила документации. Команда туда не ходит, кроме первого месяца.

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

В описании тикета. ТЗ дописывается в описание Jira/YouTrack/Linear. Разработчик видит его при открытии тикета — некуда не пойдёшь.
В Markdown-файле в репе. tests/plans/PROJ-1234.md, ссылка из тикета. Удобно для проектов, где тесты лежат рядом с кодом. Можно ревьюить как обычный PR.
В описании PR с тестами. Когда я открываю PR с автотестами на фичу, в описании первым блоком кладу ТЗ. Кто ревьюит тесты — сразу видит, что покрыто и что нет.

В Confluence файлы тоже остаются, но как архив. Living-документ — там, где смотрит команда каждый день.

Что делает ТЗ полезным

Прямой язык

«Проверяется корректность функционала отображения списка элементов» — это не язык. Это страх ответственности. Пиши «проверяю, что в списке отображаются 20 элементов на страницу, остальные — на следующих страницах через пагинацию».

Конкретные числа

«Длинная статья» — что это? 1000 символов или 100 000? Пиши: «статья 50 000 символов сохраняется без потерь, статья 60 000 отдаёт ошибку 413».

Привязка к коду

Если есть ссылка на функцию — давай. DraftService.merge() в src/draft/service.ts:123 — разработчик одним кликом смотрит код. Без ссылки он будет искать по проекту.

Без BDD-ритуала

Если в команде не пишут код в Gherkin (а в большинстве — не пишут), Given-When-Then в ТЗ — лишний слой. Простые «1. Сделал X. 2. Увидел Y» работают так же хорошо. Не строй ритуала вокруг формата.

Что не зашло

Шаблон IEEE 829 целиком. 15 разделов, половина — про процесс, не про продукт. На небольшом проекте это бюрократия без выгоды.
«Стратегия тестирования» отдельным документом. Стратегия — это «у нас тестовая пирамида X% юнитов, Y% API, Z% e2e». Один раз написал, висит на странице команды. В каждом ТЗ её повторять не нужно.
Тест-кейсы в Excel/TestRail. Прокликивал руками — нашёл. После релиза кто-то обновляет статус «pass/fail». Никакой ценности для команды разработки. Если есть автотесты, кейсов в TestRail быть не должно — они уже в коде.
ТЗ-документ на 30 страниц с подробным описанием каждого позитивного и негативного кейса. Это переводная работа: ты переписываешь то же самое тремя способами (тикет, кейс, тест). Один источник правды — код тестов с описаниями.

Чек-лист готовности

ТЗ помещается на одной странице?
Есть раздел «вне скоупа»?
Есть разделение «что делает QA» и «что делает разработчик»?
Сценарии написаны на языке пользователя, не на языке тест-кейсов?
Документ ссылается на тикет, тикет — на документ?
Разработчик прочитал и поставил палец/комментарий перед началом работы?

Главный показатель хорошего ТЗ — на его основе разработчик и QA одинаково понимают, что они делают. Если после прочтения у разработчика есть пять вопросов — документ не работает. Если PR с фичей пришёл и в нём ровно те юнит-тесты, которые ты ожидала, — работает.