При тестировании требований нужно с разных сторон анализировать требования (то есть документацию или точечные требования, указанные, например, в задаче менеджером — нередко их называют “критериями приема” задачи).

Завершенность

● “Пароли должны храниться в зашифрованном виде” Каков алгоритм шифрования?

● “Экспорт осуществляется в форматы PDF, PNG и т.д.” Что понимается под “и т.д.”?

● “... см. выше” А куда – выше? Насколько выше

Атомарность

“Когда пользователь входит в систему, должно отображаться приветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание”. Все три ситуации заслуживают отдельных и куда более детальных описаний требований.

Непротиворечивость

“После успешного входа в систему пользователя, не имеющего права входить в систему…” Как он успешно вошел в систему, если не имел такого права? “712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» Так все же красной или синей?

Однозначность

“Приложение должно поддерживать передачу больших объемов данных”. Насколько больших? “В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно”. Звучит красиво, но нереализуемо и непонятно

Выполнимость

“Настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трехмерного ввода”. Долго, дорого и бесполезно для конечного пользователя. “Система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты” В принципе нереализуемо.

Обязательность

● Требование было добавлено “на всякий случай”, хотя реальной потребности в нем не было и нет.

● Требованию выставлены неверные значения приоритета по критериям важности и/или срочности.

● Требование устарело, но не было переработано или удалено.

Прослеживаемость

● Требования не пронумерованы, не структурированы, не имеют оглавления и работающих перекрестных ссылок.

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

● Набор требований неполный, носит отрывочный характер с явными пробелами.

Модифицируемость

● Изменение требования порождает противоречивость.

● Требования изначально противоречивы. В такой ситуации внесение изменений усугубляет ситуацию.

● Требования представлены в неудобной для обработки форме.

Проранжированность

● Неверно выставлен приоритет по важности для конечного пользователя.

● Неверно выставлен приоритет по стабильности требований, которые в самое ближайшее время могут претерпеть кардинальные изменения.

● Неверно выставлен приоритет по срочности, нарушая последовательность реализации функций ПО, ожидаемых заказчиком.

Корректность и проверяемость

● Опечатки.

● Неаргументированные требования к дизайну и архитектуре.

● Плохое оформление текста и сопутствующей графической информации, грамматические, пунктуационные и иные ошибки в тексте.

● Неверный уровень детализации.

Примерный алгоритм работы тестировщика с требованиями

1. Получение и изучение требований:
   • Ознакомление с документацией проекта
   • Участие в обсуждениях и встречах по требованиям
2. Анализ требований:
   • Проверка на соответствие критериям качества (завершенность, атомарность, непротиворечивость и т.д.)
   • Выявление неясностей, пробелов или противоречий
3. Уточнение требований:
   • Формулировка вопросов к аналитикам или заказчикам
   • Участие в обсуждениях для прояснения деталей
4. Разработка тестовой документации:
   • Создание тест-кейсов на основе требований
   • Разработка чек-листов для проверки функциональности
5. Проверка покрытия:
   • Использование матрицы трассировки для соотнесения требований и тестов
   • Убеждение, что все требования покрыты тестами
6. Выполнение тестирования:
   • Проведение тестов на соответствие требованиям
   • Документирование результатов и найденных несоответствий
7. Обратная связь:
   • Сообщение о найденных проблемах в требованиях
   • Предложение улучшений или уточнений к требованиям
8. Обновление тестовой документации:
   • Корректировка тестов при изменении требований
   • Создание новых тестов для новых или измененных требований
9. Повторение цикла:
   • Возвращение к анализу при появлении новых или изменении существующих требований

Этот процесс итеративный и может повторяться на протяжении всего жизненного цикла проекта.