Приведи пример противоречивого требования

Пример противоречивого требования и его разбор

Один из классических примеров, с которым я сталкивался в реальной практике, звучит так:

"Система должна позволять пользователю вводить неограниченное количество текста в поле комментария, но при этом время сохранения комментария не должно превышать 2 секунд при любой нагрузке на сервер."

Почему это требование противоречиво?

Здесь есть два ключевых условия, которые вступают в прямой конфликт друг с другом с технической и логической точек зрения:

1. Функциональное условие: Неограниченный объем вводимых данных.
2. Нефункциональное условие: Жесткое ограничение по времени выполнения операции (2 секунды) при любых условиях.

Анализ противоречия

• С технической стороны: "Неограниченное количество текста" подразумевает, что пользователь может вставить, например, целую книгу объемом в 10 МБ или более. Обработка такого объема данных (валидация, санитизация, запись в базу данных, индексация) физически не может всегда укладываться в 2 секунды. Нагрузка на сеть, дисковую подсистему БД и процессор делает это невозможным. Более того, само понятие "при любой нагрузке" (пиковые часы, фоновые задачи) исключает гарантированность временного ограничения.
• С логической стороны: Требование не определяет, что важнее — бесконечный объем или скорость. Это создает поле для конфликта между отделами: Product Owner настаивает на удобстве для пользователя, а архитектор или DevOps — на стабильности и производительности системы.

Как действовать QA-инженеру при выявлении такого требования?

1. Немедленно зафиксировать противоречие. Я создаю задачу в трекере (например, Jira) или делаю пометку прямо в спецификации, явно указывая на конфликтующие пункты.

2. Инициировать уточнение у стейкхолдеров. Задаю уточняющие вопросы на планировании или организую отдельную встречу с аналитиком и разработчиками:

    *   "Что мы подразумеваем под "неограниченным количеством"? Есть ли разумный практический предел (например, 10 000 символов)?"
    *   "Является ли лимит в 2 секунды жестким SLA или желаемым таргетом? Что важнее в случае выбора: принять большой комментарий дольше или отклонить его, но уложиться в срок?"
    *   "Требование "при любой нагрузке" — это 100-й процентиль? Готовы ли мы к значительному удорожанию инфраструктуры для его обеспечения?"

1. Предложить варианты решений. Как опытный инженер, я не просто указываю на проблему, а предлагаю пути ее решения, основанные на аналогичном опыте:

    *   **Ввести разумное ограничение:** "Комментарий до 5000 символов сохраняется гарантированно за 2 секунды. Более длинные тексты принимаются, но без жестких временных гарантий."
    *   **Изменить метрику:** "Время сохранения комментария объемом до 5000 символов не превышает 2 секунд в 95% случаев при стандартной нагрузке."
    *   **Реализовать асинхронную обработку:** "Любой комментарий мгновенно принимается системой (за <1 сек.), а фоновая обработка (сохранение, индексация) происходит асинхронно."
    *   **Разделить на разные сценарии:** "В основном интерфейсе — поле до 1000 символов с жестким лимитом в 2 сек. Для длинных текстов — отдельный интерфейс "Документ" с иными требованиями к производительности."

Пример оформления баг-репортата на противоречивое требование

**Заголовок:** [Требования] Противоречие между неограниченной длиной комментария и временем сохранения.

**Описание:** В спецификации FR-123, пункты 4.5 и 8.12, указаны взаимоисключающие требования.
P.4.5: Пользователь может ввести комментарий неограниченной длины.
P.8.12: Операция сохранения комментария должна выполняться ≤ 2 секунд при 100% нагрузке.

**Шаги воспроизведения:** Прочитать спецификацию FR-123.
**Фактический результат:** Требования технически несовместимы.
**Ожидаемый результат:** Требования должны быть согласованы и не противоречить друг другу.
**Серьезность:** Блокирующая (Blocker) для проектирования и разработки.
**Приоритет:** Высокий (High).

**Предложение по решению:** Запросить уточнение у владельца продукта и системного архитектора. Варианты на обсуждение:
1. Ввести лимит в 5000 символов для гарантии времени ответа.
2. Ослабить требование по времени до "95-й процентиль при пиковой нагрузке".

Итог: Противоречивое требование — не просто ошибка в документации, а серьезный проектный риск. Роль QA — выявить его как можно раньше, поднять наверх и способствовать его разрешению через четкие вопросы и предложения, переводя субъективные пожелания в измеримые и реализуемые критерии. Это экономит команде недели будущей работы и потенциального переделывания функционала.