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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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