Какие знаешь критерии хороших требований?

Критерии хороших требований к программному продукту

Хорошие требования — это фундамент успешного проекта. Они обеспечивают понимание между всеми участниками (бизнес, разработка, тестирование) и минимизируют риски недоразумений, переделок и дефектов. Как QA Engineer, я оцениваю требования прежде всего с точки зрения их тестируемости и однозначности. Основные критерии можно разделить на несколько групп.

1. Критерии качества содержания (что должно быть описано)

• Полнота (Completeness): Все значимые аспекты функциональности, включая граничные условия (boundary conditions), обработку ошибок, зависимости от других систем, требования к производительности, безопасности и данным, должны быть описаны. Неполные требования приводят к незапланированной работе и дефектам.
• Непротиворечивость (Consistency): Требования внутри одного документа и между связанными документами (например, пользовательские сценарии и технические спецификации) не должны противоречить друг другу. Например, если в одном месте указано "логин по email", а в другом — "логин по телефону", это прямое противоречие.
• Однозначность и ясность (Unambiguous & Clear): Требования должны быть понятны всем сторонам без необходимости дополнительных разъяснений. Использование конкретных, измеряемых терминов вместо субъективных. "Система должна быть быстрой" — плохо. "95% запросов должны обрабатываться менее 2 секунд при нагрузке 1000 пользователей" — хорошее, тестируемое требование.

2. Критерии качества формы (как это описано)

• Тестируемость (Testability): Это ключевой критерий для QA. Из требования должно быть возможно вывести четкие тестовые случаи (test cases). Оно должно описывать конкретное поведение системы при конкретных условиях и входных данных, а также ожидаемый результат.

  // Пример плохого (не тестируемого) требования: "Система должна предоставлять релевантные результаты поиска".
  // Пример хорошего (тестируемого) требования: 
  // "При вводе ключевой фразы 'blue widget' в поле поиска на главной странице и нажатии кнопки 'Search', 
  // система должна отобразить список продуктов, в названии или описании которых содержится эта фраза, 
  // отсортированный по релевантности (первыми показываются продукты с фразой в названии)."
  

• Атрибутированность (Traceability): Каждое требование должно иметь уникальный идентификатор (например, FR-001, US-005). Это позволяет легко ссылаться на него в тест-кейсах, отчетах о дефектах и планах тестирования, обеспечивая прослеживаемость от идеи до проверки.
• Структурированность и организация: Требования должны быть логически организованы — по модулям системы, по типам (функциональные, нефункциональные), по приоритету. Это помогает планировать тестирование и разработку.

3. Практические аспекты и проверки

• Приоритетность (Prioritized): Требования должны иметь указание на важность (например, MoSCoW: Must have, Should have, Could have, Won't have). Это помогает фокусировать усилия тестирования на наиболее критичных функциях, особенно при ограниченных временных ресурсах.
• Реализуемость (Feasibility): Требование должно быть технически реализуемо в рамках проекта и его ограничений (время, бюджет, технологии). QA Engineer может помочь выявить нереализуемые требования, задавая вопросы о деталях реализации и граничных случаях.
• Верифицируемость (Verifiable): По завершении реализации должно существовать четкое и объективное доказательство, что требование выполнено. Чаще всего это результат выполнения тестовых случаев.

Пример проверки требования с точки зрения QA

Рассмотрим требование: "Пользователь может восстановить пароль через email."

Как QA, я задаю вопросы, чтобы сделать его "хорошим":

• Условия: Что является условием для запуска процесса? (Нажатие ссылки "Забыли пароль?" на форме логина).
• Входные данные: Что пользователь должен ввести? (Только email, с которым он регистрировался).
• Ожидаемый результат: Что происходит в системе?

    1.  Если email найден в системе: отправляется письмо с уникальной ссылкой для сброса пароля.
    2.  Если email не найден: отображается сообщение "Email не найден в системе".

• Граничные случаи: Как обрабатываются некорректные данные? (Ввод неформата email, пустой строки).
• Зависимости: Нужна ли работающая почтовая служба? Каков срок жизни ссылки?

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

Для меня, как тестировщика, идеальные требования — это не просто список желаний, а формализованный контракт на поведение системы, который служит основой для создания эффективного тестового покрытия (test coverage) и позволяет предсказать и предотвратить множество дефектов еще до начала coding.