Какие требования считаются качественными

Какие требования считаются качественными?

Качественные требования — это основа успешной разработки ПО. Они обеспечивают чёткое понимание между заказчиком, разработчиками и тестировщиками, минимизируют риски доработок и срыва сроков. Как QA Engineer, я оцениваю требования по нескольким ключевым критериям, часто используя мнемонику SMART или INVEST, адаптированную для требований.

Ключевые характеристики качественных требований

1. Корректность и точность (Correctness & Unambiguity)

   • Требование должно точно отражать потребность заказчика или бизнеса.
   • Формулировка должна быть однозначной, исключающей двойное толкование. Избегаем слов "быстрый", "удобный", "современный" без количественных или конкретных метрик.
   • Пример плохого требования: "Система должна быстро обрабатывать запросы".
   • Пример качественного требования: "Система должна обрабатывать 95% API-запросов типа POST /api/v1/order в течение 2 секунд при нагрузке до 1000 одновременных пользователей".

2. Полнота (Completeness)

   • Требование должно описывать все необходимые аспекты: что делает система, при каких условиях, какие данные использует и какой результат ожидается. Часто для этого используется шаблон User Story с критериями приемки (Acceptance Criteria, AC).
   • Пример User Story с AC:

     Как: Авторизованный пользователь
     Чтобы: Добавить товар в корзину
     Я хочу: Нажать кнопку "В корзину" на странице товара
     
     Критерии приемки (AC):
     1. Когда пользователь нажимает кнопку "В корзину" для доступного товара,
        Тогда счетчик товаров в иконке корзины в хедере увеличивается на 1.
     2. Когда пользователь нажимает кнопку "В корзину" для недоступного товара (нет на складе),
        Тогда кнопка неактивна и отображается тултип "Товар закончился".
     3. Когда пользователь переходит на страницу корзины,
        Тогда ранее добавленный товар отображается в списке с правильной ценой и названием.
     

3. Непротиворечивость (Consistency)

   • Требования в рамках одной системы (и между связанными системами) не должны противоречить друг другу. Один термин должен означать одно и то же во всех документах (например, "корзина" vs "заказ" vs "черновик").
   • Пример противоречия:

     * Требование А: "Пользовательский пароль должен быть не менее 6 символов".
     * Требование Б: "Пользовательский пароль должен быть не менее 8 символов".

• Такие конфликты должны быть выявлены и разрешены на этапе анализа требований.

1. Проверяемость (Testability)

   • Это ключевой для QA критерий. По требованию должно быть возможно создать однозначный тест-кейс или чек-лист, который позволит объективно определить, выполнено требование или нет. Если требование нельзя проверить, его нельзя и реализовать корректно.
   • Пример непроверяемого требования: "Интерфейс должен быть интуитивно понятным". (Как измерить?)
   • Пример проверяемого требования: "Новый пользователь должен выполнить регистрацию, следуя подсказкам на экране, не более чем за 3 минуты. Проверяется юзабилити-тестированием с 5 новыми пользователями."

2. Выполнимость (Feasibility)

   • Требование должно быть реализуемо в рамках заданных ограничений: бюджет, сроки, технологический стек, производительность команды. QA-специалист может косвенно оценить это, понимая сложность тестирования подобной функциональности.

3. Трассируемость (Traceability)

   • У каждого требования должен быть уникальный идентификатор (например, FUNC-123). Это позволяет связать его с дизайном, тест-кейсами (TC-456), дефектами (BUG-789) и кодом. В случае изменений легко оценить их влияние.
   • Пример трассировки в Jira или подобной системе: Эпик -> Функция -> Задача/История -> Критерии приемки -> Тест-кейсы -> Результаты прогонов -> Дефекты.

4. Атомарность (Atomicity)

   • Требование должно описывать одну, законченную функцию или её часть. Его нельзя разбить на меньшие, независимые части без потери смысла. Это упрощает планирование, реализацию и тестирование.
   • Пример нефтомарного требования: "Система должна отправлять email-уведомление пользователю и записывать лог в базу данных при регистрации". (Это два разных требования: отправка уведомления и логирование).

Роль QA в обеспечении качества требований

QA Engineer не пассивно принимает требования, а активно участвует в их анализе и ревью (Requirements Review). Наша задача — задавать уточняющие вопросы:

• "Что произойдёт, если поле оставить пустым?"
• "Как система должна вести себя при одновременном доступе двух пользователей к одним данным?"
• "Каковы граничные значения для этого поля ввода?"
• "Как это требование связано с уже реализованной функцией X?"

Мы часто используем техники тест-дизайна (например, создание Mind Map, таблицы принятия решений) уже на этапе анализа требований, чтобы выявить неочевидные сценарии, "дыры" и потенциальные риски.

Практический пример анализа

Исходное "сырое" требование от заказчика: "Нужна кнопка экспорта данных в Excel".

После анализа и уточнений с QA и разработчиками получаем набор качественных требований:

• FUNC-101: Реализовать выгрузку данных из отчёта "Продажи за период" в формате .xlsx.
• AC-101.1: Кнопка "Экспорт в Excel" активна только когда в отчёте есть данные.
• AC-101.2: Выгружаются все колонки, видимые пользователю в текущем представлении таблицы, с сохранением порядка.
• AC-101.3: В выгрузку добавляется лист "Инфо" с названием отчёта, датой генерации и именем пользователя.
• AC-101.4: При нажатии кнопки появляется индикатор загрузки. Файл размером до 10 МБ должен быть сформирован и скачан браузером за время ≤ 30 секунд.
• AC-101.5: Название файла: Sales_Report_YYYY-MM-DD.xlsx.

Каждое из этих уточнений проверяемо, атомарно и однозначно, что позволяет команде эффективно работать и минимизировать количество дефектов, вызванных недопониманием.