Ответ
Двусмысленные (размытые) требования не имеют четких критериев проверки, что приводит к разным интерпретациям и дефектам.
Примеры двусмысленных требований и их уточнение:
| Двусмысленная формулировка | Проблема | Четкое, измеримое требование |
|---|---|---|
| «Система должна работать быстро» | Не определены метрики скорости. | «95% запросов к API должны обрабатываться менее чем за 200 мс при нагрузке до 1000 RPS.» |
| «Приложение должно быть удобным» | «Удобство» субъективно. | «Ключевой пользовательский сценарий (оформление заказа) должен выполняться не более чем за 3 клика из главного меню.» |
| «Поддерживать мобильные устройства» | Не указаны ОС, версии, разрешения. | «Приложение должно корректно отображаться и функционировать на iOS 15+ и Android 11+ для экранов с плотностью пикселей от 320dp до 480dp.» |
| «Пользователь может загружать файлы» | Не заданы ограничения. | «Пользователь может загружать один файл форматов JPG, PNG или PDF размером не более 5 МБ.» |
| «Ошибки должны логироваться» | Не определен уровень, формат, содержание. | «Все ошибки уровня ERROR и выше должны записываться в файл app.log в формате JSON, содержащий timestamp, уровень, сообщение и stack trace.» |
Роль QA в уточнении требований:
- Задавать конкретные вопросы: «Что значит "быстро"?», «Как мы поймем, что требование выполнено?».
- Предлагать критерии приемки (Acceptance Criteria): Формулировать требования в виде проверяемых условий.
- Настаивать на измеримости: Требование должно иметь количественные или однозначные качественные метрики для тестирования.