Что такое хорошее требование?

Хорошее требование: критерии качества

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

Ключевые атрибуты хорошего требования (акроним SMART и не только)

Хорошие требования соответствуют ряду критериев, часто описываемых аббревиатурой SMART и другими принципами:

• Конкретность и однозначность (Specific & Unambiguous):

    *   Требование должно иметь только одно толкование. Исключаются слова "быстрый", "удобный", "примерно". Вместо них используются измеримые и конкретные термины.
    *   **Плохо:** "Система должна быстро обрабатывать заказы".
    *   **Хорошо:** "Система должна обрабатывать 95% новых заказов в течение 2 секунд при нагрузке до 100 параллельных пользователей".

• Измеримость и проверяемость (Measurable & Testable):

    *   Это ключевой для QA аспект. Должна существовать возможность объективно проверить, выполнено требование или нет, с помощью теста, инспекции, анализа или демонстрации.
    *   **Плохо:** "Интерфейс должен быть пользовательским".
    *   **Хорошо:** "Новый пользователь должен суметь создать заказ, пройдя не более 3 экранов и не сделав более 5 кликов, после 10-минутного ознакомления с инструкцией".

• Достижимость и реализуемость (Achievable & Feasible):

    *   Требование должно быть технически реализуемо в рамках заданных ограничений (бюджет, сроки, технологии). Нереалистичные требования ведут к срыву сроков и недовольству.

• Актуальность и важность (Relevant):

    *   Каждое требование должно соответствовать бизнес-целям проекта и быть необходимым. "Хотелки", не влияющие на ценность продукта, создают лишнюю сложность.

• Прослеживаемость (Traceable):

    *   Требование должно иметь уникальный идентификатор (например, `FR-101`). Это позволяет связать его с родительской бизнес-целью, а также с дизайнерскими решениями, тест-кейсами и дефектами. Это критически важно для анализа покрытия и оценки последствий изменений.

• Корректность (Correct):

    *   Требование должно точно отражать потребности заказчика и не содержать внутренних противоречий.

• Полнота (Complete):

    *   Требование должно быть самодостаточным и описывать все необходимые условия, входные и выходные данные, без отсылок к неописанным сущностям.

• Непротиворечивость (Consistent):

    *   Требования не должны конфликтовать друг с другом или с другими документами проекта. Один термин должен использоваться в одном значении.

• Приоритезированность (Prioritized):

    *   Каждое требование должно иметь приоритет (например, MoSCoW: Must have, Should have, Could have, Won't have). Это помогает команде фокусироваться на самом важном и гибко управлять релизами.

Пример хорошего функционального требования

# Уникальный ID и заголовок для прослеживаемости
REQ-ID: FR-205
Заголовок: Добавление товара в корзину

Описание: Авторизованный пользователь должен иметь возможность добавить выбранный товар в свою корзину для покупок.

Критерии приемки (Acceptance Criteria):
1. ДАННЫТОВАР С КОЛИЧЕСТВОМ НА СКЛАДЕ > 0
   И пользователь на странице деталей этого товара
   КОГДАон нажимает кнопку "Добавить в корзину"
   ТОтовар появляется в мини-корзине в шапке сайта
   И общее количество товаров в корзине увеличивается на 1
   И отображается уведомление "Товар 'Название' добавлен в корзину"

2. ДАННЫТОВАР С КОЛИЧЕСТВОМ НА СКЛАДЕ = 0
   И пользователь на странице деталей этого товара
   КОГДАон нажимает кнопку "Добавить в корзину"
   ТОпоявляется сообщение "Товар временно отсутствует"
   И кнопка "Добавить в корзину" становится неактивной
   И содержимое корзины не изменяется.

Это требование является:

• Конкретным (описаны состояния товара).
• Проверяемым (четкие шаги и ожидаемые результаты для QA).
• Непротиворечивым.
• Полным (рассмотрены основные сценарии).
• Прослеживаемым (имеет FR-205).

Роль QA-инженера в работе с требованиями

QA-инженер не просто пассивно принимает требования, а активно участвует в их улучшении:

1. Ревью требований на ранних этапах: Поиск неоднозначностей, противоречий, "дыр" и непроверяемых утверждений.
2. Уточнение критериев приемки: Помощь в формулировке четких и полных критериев, на основе которых будут строиться тесты.
3. Запрос примеров и пользовательских сценариев: Перевод абстрактных пожеланий в конкретные use case.
4. Оценка тестируемости: Если требование невозможно адекватно проверить, это сигнал о необходимости его переформулировать.

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