На любом живом проекте тестовая документация касается не только QA. Аналитики проверяют её на соответствие требованиям, разработчики — на техническую реализуемость, менеджеры — следят за готовностью к релизу. При этом исторически TMS — это пространство тестировщиков. Остальные роли оказываются за его пределами.

Типичная схема взаимодействия

Когда аналитику нужно убедиться, что тест-кейсы корректно отражают требования, начинается знакомый цикл:

1. QA выгружает кейсы в Confluence, Word или PDF.
2. Аналитик изучает их отдельно от исходного артефакта.
3. Замечания фиксируются в отдельном документе, тикете или чате.
4. QA возвращается в TMS, вносит правки, снова выгружает.
5. Цикл повторяется.

С разработчиком — похожая история: вопрос про технический нюанс шага обсуждается в мессенджере, а к кейсу по итогам обсуждения никто не возвращается. С менеджером ещё проще: он просто не видит, что происходит с тестовой документацией, пока не спросит напрямую.

У всех этих сценариев есть одна общая черта — обсуждение ведётся вне того артефакта, о котором идёт речь. Контекст теряется, правки откладываются, часть замечаний не доходит до автора.

Наблюдатели в DoQA

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

В релизе 4.1 наблюдатели получили возможность оставлять комментарии к тест-кейсам и чек-листам. Функциональность та же, что и у тестировщиков: привязка к конкретному артефакту, древовидные обсуждения, упоминания через @, статусы «решён» / «не решён», сохранение истории вне зависимости от версии кейса.

Как это работает в разных ролях

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

Для аналитика

Ревью соответствия тест-кейсов требованиям — одна из классических задач аналитика на проекте. Теперь она решается внутри TMS: аналитик читает кейс, оставляет комментарий прямо к шагу, где есть расхождение с документацией. Автор кейса получает уведомление, дискуссия ведётся в контексте артефакта, история сохраняется. Никаких выгрузок, промежуточных документов и потерянных правок.

Для разработчика

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

Для менеджера проекта, PM или PO

Наблюдение за прогрессом ревью перестаёт требовать отдельных созвонов и отчётов. Руководитель видит, сколько замечаний открыто, кто за них отвечает и в каком статусе находится согласование тестовой документации по релизу. Асинхронная работа становится действительно асинхронной — без необходимости уточнять «как дела?» в рабочих чатах.

Для дизайнера и других специалистов

UI-сценарии, пограничные состояния интерфейса — всё это часто лучше всего знает дизайнер. Возможность оставить комментарий к тест-кейсу позволяет его экспертизе попадать туда, где она действительно пригодится — а не растворяться в комментариях Figma, до которых QA вряд ли дойдёт.

Что это меняет на уровне процесса

Тестовая документация перестаёт быть пространством одного отдела. Обсуждения ведутся в контексте конкретных артефактов, история решений сохраняется вместе с ними, а новые участники команды видят не только текст кейса, но и логику, по которой он написан именно так.

По сути, это превращение статичной документации в общий инструмент всей команды — а не только QA-отдела.

Комментарии к тест-кейсам и чек-листам доступны всем ролям, включая наблюдателей, в релизе 4.1. Количество наблюдателей на всех тарифах DoQA не ограничено.