На что обращать внимание при работе с тз?

На что обращать внимание при работе с техническим заданием (ТЗ)

При работе с техническим заданием (ТЗ) QA-инженер должен рассматривать его не как статичный документ, а как живой артефакт, который является основой для тестирования, но также источником множества рисков. Грамотный анализ ТЗ на ранних этапах предотвращает до 60% критических дефектов, связанных с недопониманием требований. Вот ключевые аспекты, на которые я обращаю внимание.

1. Полнота и непротиворечивость требований

Это первое, что я проверяю. Каждое требование должно быть самодостаточным и не противоречить другим частям документа.

• Отсутствие двусмысленностей: Фразы типа «примерно», «как правило», «быстро» неприемлемы. Требование «Система должна быстро отображать отчет» нуждается в уточнении: «95% отчетов должны отображаться менее чем за 2 секунды при нагрузке до 100 одновременных пользователей».
• Связность сценариев: Проверяю, чтобы бизнес-логика работы одной функциональности не нарушалась при описании другой. Например, если в одном разделе указано, что заказ можно отменить в течение часа, а в другом — что после оплаты доступен возврат только на следующий день, это противоречие, которое нужно разрешить.

2. Декомпозиция и тестопригодность

Требование должно быть проверяемым (тестопригодным). Если его нельзя протестировать, оно бесполезно для QA.

• Критерии приемки (Acceptance Criteria): Ищу их в ТЗ. В идеале они должны быть в формате Given-When-Then. Их отсутствие — красный флаг.

  # Пример хорошего критерия приемки:
  Feature: Отмена заказа
      Scenario: Отмена неоплаченного заказа
          Given пользователь находится на странице деталей своего неоплаченного заказа
          When пользователь нажимает кнопку "Отменить заказ"
          Then заказ переходит в статус "Отменен"
          And пользователю приходит email-уведомление "Ваш заказ №ХХ отменен"
  

• Граничные условия: Анализирую, описаны ли явно границы полей, лимиты, состояния. Например: «Максимальный размер загружаемого файла — 50 МБ». Я сразу планирую тесты на значения 49.9 МБ, 50 МБ, 50.1 МБ.

3. Учет нефункциональных требований (NFR)

Часто ТЗ фокусируется только на функционале, но производительность, безопасность, юзабилити и совместимость критически важны.

• Производительность: Указаны ли целевые показатели (время отклика, RPS)?
• Безопасность: Описаны ли требования к аутентификации, авторизации, валидации входных данных?
• Совместимость: С какими браузерами, ОС, версиями приложения должна сохраняться работоспособность?

4. Взаимодействие с внешними системами (интеграции)

Я тщательно изучаю разделы, описывающие API, интеграции со сторонними сервисами (платежки, смс-шлюзы, аналитика).

• Формат данных и протоколы: (REST, SOAP, GraphQL).
• Сценарии ошибок: Как система должна реагировать на недоступность или некорректный ответ от внешнего сервиса? Часто это упускается в ТЗ.

  // Пример: В ТЗ должно быть описано, как обрабатывать такой ответ от платежного шлюза
  {
    "status": "error",
    "code": "INSUFFICIENT_FUNDS",
    "message": "Недостаточно средств на карте"
  }
  

5. Роли пользователей и права доступа

Четко ли определены роли (администратор, модератор, обычный пользователь, гость) и их разрешения (CRUD — Create, Read, Update, Delete)? Я строю матрицу доступа, чтобы наглядно выявить пробелы.

6. Процесс работы с ТЗ: коммуникация и артефакты

Само ТЗ — лишь часть процесса. Мои действия:

• Задаю вопросы: Составляю список уточняющих вопросов (clarification request) и обсуждаю с аналитиком/продукт-менеджером. Молчание — враг качества.
• Использую техники тест-дизайна: При анализе применяю классы эквивалентности, анализ граничных значений, состояния и переходы прямо на основе текста ТЗ. Это помогает найти скрытые требования.
• Фиксирую согласованное: Все решения и уточнения вносятся в ТЗ или связанные документы (например, в тест-анализ или чек-лист). Это страхует от «а я думал, что вы договорились иначе».
• Валидирую сценарии: Прохожу мысленно по ключевым пользовательским сценариям, чтобы убедиться в их логичности и завершенности.

Заключение

Внимательный анализ ТЗ — это проактивное тестирование. Он позволяет выявить дефекты требований («баги в ТЗ») до написания кода, что в десятки раз дешевле их исправления на поздних стадиях. Основная цель — добиться общего, однозначного понимания того, что мы строим, между заказчиком, аналитиком, разработчиком и тестировщиком. Качественное ТЗ — это карта, которая ведет к успешному продукту, и задача QA-инженера — убедиться, что эта карта точна и полна.