Очень часто можно услышать, в том числе и на собеседованиях: «На проекте нет требований, как вообще тестировать?» 

И вот тут начинается самое интересное.

На многих проектах документации или нет совсем, или она давно устарела. И в этот момент тестировщик не должен терять почву под ногами - он становится связующим звеном между продуктом, кодом и бизнесом. Теперь от него зависит очень многое.

Как это работает на практике:

Берём за основу то, что уже работает в проде (или последнего релиз-кандидата) - фактическое as-is.

Уточняем у бизнеса: что критично для пользователя, где потенциальные деньги и репутационные риски.

Сверяем с разработкой: задумывалось ли именно так, как сделано?

Всё фиксируем в артефактах (тест-планах, use-кейсах, чек-листах/тест-кейсах).

При этом помним, что подход к тестированию зависит от контекста: где-то хватит чек-листа, а где-то нужны тест-кейсы.

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

- Собери требования сам (аналитика, разработка).

- Изучи продукт глазами пользователя и попробуй построить ожидания клиента.

- Построй модель поведения реального юзера.

- Оформи happy-path приложения и ключевые негативные сценарии.

- Фиксируй всё в чек-листы, тест-кейсы, схемы или заметки.

- В результате у тебя получится упорядоченная система, на основе которой уже можно базировать полноценное тестирование.

QA может превратить хаос в понятные правила и сценарии.

Главное тут - внимание и методичный подход, необходимо уметь общаться с бизнесом и разработкой, фиксировать, документировать и упорядочивать знания команды.

p.s. Не забывайте запрашивать обратную связь от команды и бизнеса по процессам тестирования.