Тестирование требований

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

Что тестируется: требования, описывающие функциональность проекта, пользовательский, аппаратный, программный  интерфейсы, критерии эффективности, риски, критерии безопасности и корректности системы

Глядя на диаграмму (согласна, так себе надежность статистики, уровня белстата примерно, но все же), большинство ошибок тянется именно из требований к ПО,  поэтому нужно с этим как-то бороться, т.е. сделать так, чтобы не было следующих проблем:

• непонятность требований,
• частая изменяемость,
• изменения, вносимые в последний момент,
• неверная трактовка требований.

Из-за всего выше перечисленного может произойти следующее:

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

Чтобы избежать всего этого следует сделать так , чтобы требования были :

• завершенными,
• непротиворечивыми,
• корректными,
• недвусмысленными,
• проверяемыми,
• приоритизированными.

Также хороший набор требований должен быть модифицируемым, прослеживаемым, проранжированным.

Техники тестирования требований :

• Взаимный просмотр:
• беглый просмотр — автор показывает свою работу коллегам, они в свою очередь дают свои рекомендации, высказывают свои вопросы и замечания;
• технический просмотр — выполняется группой специалистов;
• формальная инспекция — привлекается большое количество специалистов, представляет собой структурированный, систематизированный и документированный подход. Минус такого варианта — тратится много времени.

2) Вопросы — если возникают вопросы, то можно спрашивать у представителей заказчика, более опытных коллег.

3) Тест-кейсы и чек-листы — хорошее требование должно быть проверяемым, чтобы это определить можно использовать чек-листы или полноценные тест-кейсы. Если можно быстро придумать несколько пунктов чек-листа — это уже хороший знак.  

4) Исследование поведения системы — необходимо мысленно смоделировать процесс работы пользователя с системой, созданной по тестируемым требованиям, после этого определить неоднозначные варианты определения системы.

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

6) Прототипирование — сделав наброски пользовательского интерфейса, легко оценить применить применение тех или иных пользовательских решений.

Бонусом для понятия как проводить тестирование требований, немного о самих требованиях:

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

1. Завершенность (требование должно содержать всю информацию, необходимую для разработчиков).
2. Ясность (требования должны быть понятными).
3. Корректность и согласованность (требование должно четко указывать на то, что должно выполнять приложение).
4. Проверяемость (способ однозначной проверки выполнено требование или нет).
5. Необходимость и полезность при эксплуатации.
6. Осуществимость (определяется балансом между ценностью и требуемыми ресурсами).
7. Модифицируемость (набор требований должен быть таким, чтобы его можно было легко модифицировать, при этом не изменяя требования в других местах).
8. Прослеживаемость (возможность  отследить связь между требованием и другими артефактами проекта, каждое требование имеет  уникальный идентификатор, по которому оно легко прослеживается).
9. Упорядоченным по важности, стабильности и срочности.

Проблемы, которые возникают при работе с требованиями:

1. Проблемы незавершенности.
2. Проблемы противоречивости.
3. Проблемы некорректности.
4. Проблемы двусмысленности.
5. Проблемы непроверяемости.
6. Проблемы непроранжированности.

Про все виды тестирования ПО