Где брал источники при отсутствии технического задания?

Поиск источников требований при отсутствии ТЗ

В реальной практике отсутствие формального технического задания (ТЗ) — ситуация распространённая, особенно в agile-средах, стартапах или при работе с legacy-системами. Опытный QA-инженер не останавливает работу, а активно инициирует и структурирует процесс сбора требований, становясь ключевым звеном в снижении рисков. Вот основные источники и стратегии, которые я использую.

1. Первичные и прямые источники информации

• Коммуникация с бизнес-заказчиком или Product Owner (PO): Самый ценный источник. Я организую сессии уточняющих вопросов, используя техники "5 почему" и "пользовательские истории", чтобы докопаться до сути потребности.

  # Пример структурирования вопроса в формате сценария:
  Когда я, как <роль пользователя>,
  хочу <выполнить действие>,
  чтобы <получить пользу/достичь цели>.
  

• Анализ существующей системы (если есть): Изучение работающего продукта — бесценно. Я документирую текущее поведение (фактическое ТЗ), создавая базу знаний в Confluence или аналогичном инструменте. Это включает анализ логов, текущей базы данных, API-документации (если доступна).
• Изучение аналогов и конкурентов (Competitive Analysis): Понимание, как аналогичную проблему решают другие, помогает сформулировать ожидания к качеству и функциональности.
• Работа с командой разработки: Диалог с разработчиками, особенно с архитектором или тимлидом, помогает понять технические ограничения, структуру данных и предполагаемую логику реализации. Часто у них уже есть неформальное понимание задачи.

2. Косвенные и сопутствующие источники

• Пользовательская аналитика и обратная связь: Если это обновление существующего продукта, изучаю отзывы в магазинах приложений, обращения в поддержку, данные инструментов аналитики (Amplitude, Google Analytics) — какие сценарии популярны, где пользователи испытывают трудности.
• Юридические и отраслевые стандарты (Compliance): Для определённых доменов (финтех, медтех, e-commerce) обязательны требования PCI DSS, GDPR, HIPAA и т.д. Их изучение формирует нефункциональные требования.
• Документация на предыдущие версии или смежные модули: Даже если нет ТЗ на новую фичу, часто есть описание старой системы, соглашения об именовании, стандарты кодирования, которые задают контекст.

3. Проактивные действия и артефакты QA

Чтобы систематизировать собранную информацию и минимизировать недопонимание, я активно создаю следующие документы:

• Чек-лист уточняющих вопросов: Универсальный список для обсуждения с PO.

    *   Целевая аудитория и её болевые точки?
    *   Критерии успеха (как измерим, что фича удалась)?
    *   Ограничения и зависимости?
    *   Приоритеты (что должно работать в первую очередь)?

• Mind maps (интеллект-карты): Визуализация функциональности, связей между компонентами и возможных сценариев использования.
• Прототипы и mock-up'ы: Даже нарисованные от руки скетчи экранов помогают выявить противоречия в логике интерфейса.
• Предварительный тест-план или список приёмочных критериев (Acceptance Criteria): Формулирую их сам и выношу на утверждение заказчику. Это лучший способ проверить, что мы поняли друг друга правильно.

Ключевая философия и итог

Моя роль в этой ситуации — не пассивно ждать ТЗ, а стать катализатором процесса его создания. Я превращаю разрозненные данные в структурированные, проверяемые требования. Ключевой навык здесь — предусмотрительность (proactive thinking) и коммуникация. Я документирую все принятые решения и допущения, чтобы в будущем они служили референсом и частью "живой" документации. Конечная цель — сместить акцент с поиска виноватых за дефект на совместное предотвращение недопонимания на ранних этапах, что в разы сокращает стоимость исправлений и повышает общую эффективность команды.