«У нас нет требований». «Требования в голове у продукт-оунера». «Просто потестируй, как считаешь нужным». Знакомые фразы? Каждый QA-специалист рано или поздно слышит их и задается вопросом: а возможно ли в принципе качественное тестирование в таких условиях? ‼️🆘

Короткий ответ: Да, можно. Но это не тестирование «без требований» — это тестирование с неявными, неформализованными или разрозненными требованиями. И в этом кроется ключевое различие.

Давайте разберемся, что такое требования на самом деле, где их искать, когда нет идеальной документации, и как выжить QA-аналитику в условиях неопределенности ⤵️

Что такое требования на самом деле?

Часто под «требованиями» ошибочно понимают документ PRD (Product Requirements Document). Но в реальности это лишь одна из форм.

Требования к ПО — это ЛЮБАЯ информация об ожидаемом составе, поведении и свойствах продукта.

Если нет документа, требования рассредоточены в других артефактах. Ваша задача как QA — стать детективом и собрать их в целостную картину. Основные источники «неявных» требований:

✅ Пользовательские истории и Acceptance Criteria (критерии приемки): Даже краткое описание в Jira — уже требование.

✅ Дизайн-макеты (Figma, Sketch): В них зашифрованы требования к интерфейсу, поведению элементов, валидации полей.

✅ Общение с продукт-оунером, бизнес-аналитиком, заказчиком: Митинги, звонки, переписка в Slack — кладезь информации.

✅ Аналоги и конкуренты (Competitive Analysis): Ожидания пользователей часто формируются на основе существующих на рынке решений. ✅ Здравый смысл и отраслевые стандарты: Кнопка «Сохранить» должна сохранять, пароль не должен отображаться открытым текстом. ✅ Старая (legacy) система: Если мы делаем новую версию продукта, старая — это живая спецификация (хоть и не идеальная)

Чек-лист: что анализировать, когда «требований нет» Используйте этот чек-лист как карту, которая поможет вам систематизировать хаос. Задавайте эти вопросы, даже если ответы на них никто явно не формулировал.

1️⃣ Из чего СОСТОИТ система? Данные и их взаимодействия: Какие сущности (пользователь, заказ, товар) будут в системе? Какие у них атрибуты? Как они связаны (один ко многим, многие ко многим)? Компоненты и их взаимодействия: Из каких крупных блоков состоит система (фронтенд, бэкенд, API, БД, микросервисы)? Как они общаются между собой?

2️⃣ Что система УМЕЕТ? (Функционал) Каковы основные пользовательские сценарии (User Flow)? Например: «Регистрация -> Поиск товара -> Добавление в корзину -> Оформление заказа».

3️⃣ КАКАЯ система? (Качества — самое часто упускаемое!)

Производительность: Сколько пользователей должно выдерживать? Какое время отклика допустимо? Удобство использования (Usability):** Интуитивно ли понятен интерфейс? Безопасность: Как защищены данные? Есть ли авторизация? Совместимость: С какими браузерами, ОС, устройствами должна работать? Надежность: Как система ведет себя при ошибках? Должна ли быть возможность восстановления данных?

4️⃣ Как система ВЗАИМОДЕЙСТВУЕТ с внешним миром? Внешние интерфейсы (API): С какими внешними сервисами интегрируется (платежки, смс-рассылка, геолокация)? Каковы форматы запросов и ответов? Пользовательский интерфейс (UI): Как происходит взаимодействие с человеком?