Что делать, если нет требований программного продукта

Стратегия работы в условиях отсутствия формальных требований

Это классическая ситуация в Agile-среде и на ранних этапах стартапов. Отсутствие формального SRS (Software Requirements Specification) не освобождает QA-инженера от ответственности за качество, а лишь меняет подход. Вот поэтапный план действий.

1. Активное прояснение и документирование контекста

Первым делом нужно превратиться в детектива и собрать максимум информации.

• Инициация диалога с заинтересованными сторонами (Stakeholders): Провожу встречи с продакт-менеджером, тимлидом, разработчиками и даже с отделом продаж или поддержки, если это возможно. Цель — понять бизнес-цель продукта, его целевую аудиторию (ЦА) и ключевые проблемы, которые он решает. Часто вместо требований есть пользовательские истории (User Stories) или просто идеи в голове продукт-оунера.
• Анализ существующих артефактов: Изучаю всё, что есть: прототипы в Figma/Sketch, конкурентов, описание задачи в трекере (Jira, Trello), техническое задание на дизайн, даже переписку в Slack/Teams.
• Создание «живых» требований: Начинаю самостоятельно документировать понимание в форме check-листов, mind maps (интеллект-карт) или простых таблиц. Этот документ становится отправной точкой для обсуждения и согласования.

2. Фокус на пользовательском опыте и бизнес-ценности

Когда нет чек-листа "что тестировать", ориентируюсь на основные принципы.

• Принцип «Не навреди»: В первую очередь проверяю, что базовый пользовательский сценарий (Happy Path) работает. Нельзя допустить, чтобы основная функция, ради которой создан продукт, была сломана.
• Тестирование на основе рисков (Risk-Based Testing): Провожу brainstorming с командой, чтобы выявить наиболее рискованные модули:

    *   Какие функции самые важные для бизнеса?
    *   Какие части системы самые новые или сложные?
    *   Где были проблемы в прошлом (в похожих модулях)?
    *   Что сильнее всего ударит по репутации, если сломается?
    *   Результатом является **приоритизированный бэклог тестирования**.

• Использование эвристик и чек-листов: Применяю стандартные подходы, такие как SFDPOT (Structure, Function, Data, Platform, Operations, Time) или FCC CUTS VIDS для построения полного набора тестов. Проверяю не только явное, но и контекстное:

  // Пример: Даже без требований я проверю для поля "Email":
  // 1. Валидный email принимается.
  // 2. Email без "@" отклоняется.
  // 3. Email с пробелами отклоняется.
  // 4. Дублирующий email (если это регистрация) отклоняется.
  // 5. Очень длинный email обрабатывается адекватно.
  // 6. Поле не ломает SQL-инъекцию.
  

3. Практические методики тестирования "вслепую"

• Исследовательское тестирование (Exploratory Testing): Это мой основной инструмент. Сессии ET позволяют одновременно изучать продукт, проектировать тесты и выполнять их. Подходы:

    *   **Свободное исследование:** Просто кликаю по всему интерфейсу, как это сделал бы новый пользователь.
    *   **Сценарийное исследование:** Выбираю конкретную пользовательскую роль (например, "админ" или "неопытный покупатель") и прохожу ключевые сценарии от ее лица.
    *   **Фиксирую все находки** в виде баг-репортов или тестовых сценариев для будущей автоматизации.

• Тестирование на основе состояний и переходов: Анализирую, какие состояния может принимать объект (например, заказ: "в корзине", "оплачен", "отправлен", "доставлен") и как между ними можно перейти. Это помогает найти пропущенные или некорректные переходы.
• Работа с эталоном: Если есть старая версия продукта или главный конкурент, использую их как неявный стандарт. Любое отклонение должно быть осознанным и обсужденным с командой.

4. Тесная интеграция в процесс разработки

• Участие в планировании (Planning): Настаиваю на включении в обсуждение каждой новой фичи. Задаю уточняющие вопросы:

    *   "Как пользователь должен это сделать?"
    *   "Что произойдет, если ввести неверные данные?"
    *   "Как эта фича связана с уже существующей функциональностью X?"
    *   Моя цель — выявить и обсудить допущения *до* начала программирования.

• Примеры и тесты как требования: Пропагандирую в команде подход ATDD (Acceptance Test-Driven Development) или BDD (Behavior-Driven Development). На этапе обсуждения мы вместе с разработчиком и PO записываем критерии приемки в виде конкретных примеров. Эти примеры потом становятся тестами.

  // Вместо требования "Система должна рассчитывать скидку" мы получаем:
  Feature: Расчет скидки для постоянных клиентов
      Scenario: Клиент с 5+ покупками получает скидку 10%
          Given у клиента есть 6 завершенных заказов в истории
          When клиент добавляет товар на сумму 1000 руб. в корзину
          Then итоговая сумма к оплате должна быть 900 руб.
  

• Непрерывная коммуникация: Работаю в тесном контакте с разработчиком, задаю вопросы по ходу реализации, тестирую инкрементально (по мере готовности отдельных частей), а не в конце спринта.

Итог: Отсутствие формальных требований — это не тупик, а возможность для QA проявить максимальную проактивность и экспертизу. Моя роль трансформируется из пассивного верификатора списка в активного исследователя, аналитика и защитника пользовательского опыта. Ключ к успеху — постоянный диалог с командой, документирование достигнутого консенсуса и фокус на ценность для бизнеса и конечного пользователя. В результате такой работы я часто становлюсь одним из главных источников "живых" требований для команды.