Ошибки и риски, связанные с требованиями

Ошибки и риски, связанные с требованиями

Введение

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

В этом уроке разберём, какие бывают проблемы с требованиями, и как тестировщик может их минимизировать.

Стоимость дефекта на разных этапах

Чем позже найден дефект — тем дороже его исправить:

Это означает: один час работы тестировщика с требованиями экономит дни работы всей команды.

Типичные проблемы с требованиями

Отсутствующие требования (Missing Requirements)

Что-то важное просто не описано. Команда разработки «угадывает» поведение системы.

Пример: Описана функция добавления товара в корзину, но не описано, что происходит при добавлении одного и того же товара дважды.

Противоречивые требования (Contradictory Requirements)

Два требования взаимно исключают друг друга.

Пример:

• REQ-10: «Неавторизованный пользователь может просматривать каталог»
• REQ-11: «Для просмотра каталога требуется авторизация»

Неоднозначные требования (Ambiguous Requirements)

Требование допускает несколько интерпретаций.

Пример: «Кнопка должна быть заметной» — заметной для кого? насколько заметной?

Нетестируемые требования (Untestable Requirements)

Нет объективного способа проверить выполнение.

Пример: «Система должна быть интуитивно понятной»

Gold-plating (Золотое покрытие)

Разработчик или тестировщик добавляет функциональность, которая не была запрошена. Это тратит время и добавляет риски.

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

Scope Creep (Расползание рамок)

Постепенное неконтролируемое добавление новых требований без оценки влияния на сроки и ресурсы.

Риск-ориентированное тестирование

Когда времени на тестирование мало, нужно расставить приоритеты. Риск-ориентированное тестирование — это подход, при котором тестируется в первую очередь то, что важнее для бизнеса и вероятнее всего сломается.

Факторы риска:

Пример матрицы рисков:

Раннее вовлечение QA в требования

Тестировщик, участвующий в обсуждении требований с самого начала, может:

• Задать вопросы, которые выявят пробелы до начала разработки
• Предложить критерии приёмки, которые сделают требование тестируемым
• Предупредить о сложности тестирования определённых сценариев
• Оценить риски, связанные с размытыми формулировками

Практика Shift Left — это принцип, при котором тестирование «сдвигается влево» по временной шкале проекта, то есть начинается как можно раньше.

Распространённые ошибки тестировщика

• Принимать непонятные требования молча — лучше задать вопрос, чем тестировать непонятно что
• Игнорировать риски — тестировать по алфавиту, а не по важности
• Не фиксировать найденные проблемы требований — устная договорённость не работает
• Тестировать только «счастливый путь» — негативные сценарии часто покрыты хуже

Что мы запомним

• Дефекты в требованиях — самые дорогие: исправление в production стоит в 100 раз дороже, чем на этапе требований
• Основные типы проблем: отсутствующие, противоречивые, неоднозначные, нетестируемые требования
• Риск-ориентированное тестирование позволяет расставить приоритеты при нехватке времени
• Раннее вовлечение QA в требования снижает стоимость дефектов
• Принцип Shift Left: начинай тестирование как можно раньше