Контекст

Тестировщик без документации работает вслепую: он проверяет не то, что должна делать система, а то, что она делает сейчас. Разница принципиальна. Если на странице оплаты кнопка называется «Продолжить», а в требованиях — «Оплатить», без документа вы этого не заметите. Документация проекта — это система координат, относительно которой QA выносит вердикт «баг» или «не баг». На реальном проекте документация распределена по слоям: бизнес-требования отвечают на вопрос «зачем мы это делаем», функциональные требования и User Story — «что именно должна делать система», макеты — «как это выглядит», контракты API — «как компоненты общаются между собой», а тестовая документация — «как мы это проверяем». Каждый слой создаёт свой автор: продакт-менеджер, аналитик, дизайнер, разработчик, тестировщик. QA — единственная роль, которая регулярно читает все слои сразу, поэтому именно тестировщик чаще всех находит расхождения между ними. Умение быстро находить нужный документ и понимать его статус (черновик, согласован, устарел) — базовый профессиональный навык, который отличает самостоятельного специалиста от исполнителя, ждущего инструкций.

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

Рабочий алгоритм

Когда вы приходите на новый проект или получаете новую задачу, соберите личную карту документации по следующему алгоритму:

• Найдите бизнес-контекст: описание продукта, цели квартала, roadmap — обычно в Confluence или Notion. Это даст понимание, что для бизнеса критично.
• Определите источник функциональных требований: страницы аналитики, User Story в Jira, PRD. Уточните у аналитика, какой из источников считается актуальным при расхождениях.
• Найдите макеты в Figma и проверьте, какая страница помечена как финальная — в больших файлах рядом живут черновики и отклонённые варианты.
• Откройте документацию API (Swagger/OpenAPI, Postman-коллекции) и убедитесь, что она генерируется из кода, а не пишется руками — от этого зависит степень доверия.
• Зафиксируйте карту у себя: артефакт → где лежит → кто владелец → как узнать про обновления (подписка, канал в Slack, уведомления Jira).

Пример из практики

Джуниор-тестировщица Аня получила задачу проверить новую форму восстановления пароля. Она открыла тикет в Jira — там было одно предложение: «Реализовать восстановление пароля по email». Аня начала тестировать «по здравому смыслу» и завела три бага: нет ограничения на количество попыток, письмо приходит без логотипа, ссылка живёт 24 часа вместо «привычных» 15 минут. Все три бага закрыли как invalid: rate limiting был описан в отдельном security-требовании и реализован на уровне шлюза, шаблон письма ещё не был передан дизайнером, а время жизни ссылки в 24 часа было явно согласовано с бизнесом в Confluence. Потратив час на чтение связанных документов до начала тестирования, Аня нашла бы страницу «Password Recovery — требования», приложенный к ней макет письма и решение по TTL ссылки. Вывод, который она сделала: тикет в Jira — это указатель на работу, а не полное описание требований. Теперь первым шагом любой задачи она собирает связанные документы и читает их, прежде чем нажать первую кнопку.

Частые ошибки

Типичные ошибки при работе с проектной документацией, которые дорого обходятся тестировщику:

• Тестировать только по тикету, игнорируя связанные документы: тикет почти всегда неполон, а детали живут в требованиях, макетах и обсуждениях.
• Доверять первому найденному документу без проверки актуальности: устаревшая страница в Confluence опаснее её отсутствия, потому что создаёт ложную уверенность.
• Не выяснять владельца документа: когда найдено расхождение, вопрос «кому писать?» не должен занимать полдня.
• Хранить знания в голове вместо карты: через месяц вы сами не вспомните, где лежало решение по граничным случаям.