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

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

Тестирование документации и требований относится к разряду нефункционального тестирования. Используются следующие основные техники тестирования требований:

• Взаимный просмотр

Взаимный просмотр («рецензирование») является одной из наиболее  используемых техник тестирования требований и может быть представлен в одной из трёх следующих форм (по мере нарастания его сложности и цены): 

• Беглый просмотр

Показ автором своей работы коллегам с целью создания общего понимания и получения обратной связи и обмен результатами работы между двумя и более авторами с тем, чтобы они высказали свои вопросы и замечания. Это самый быстрый, дешёвый и часто используемый вид просмотра.

• Технический просмотр

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

• Формальная инспекция  

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

• Вопросы.

Для повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) — задавание вопросов. 

Пример плохих и хороших вопросов к требованиям

Плохое требование 

Плохие вопросы

«Приложение должно быстро запускаться».

Хорошие вопросы

«Насколько быстро?» (Можно получить ответы «очень быстро», «максимально быстро», 

«просто быстро»). «А если не получится быстро?» «Всегда?» («Да, всегда»).

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

Плохое требование 

Плохие вопросы

«Опционально должен поддерживаться экспорт документов в формат PDF». 

«Любых документов?» (Ответы «да, любых» или «нет, только открытых».) «В PDF какой версии должен производиться экспорт?» (Сам по себе вопрос хорош, но он не даёт понять, что имелось в виду под «опционально».) «Зачем?»

Хорошие вопросы

(вопрос не раскрыт полностью.)

«Насколько возможность экспорта в PDF важна? Как часто, кем и с какой целью она будет использоваться? Является ли PDF единственным допустимым форматом для этих целей или есть альтернативы? Допускается ли использование внешних утилит (например, виртуальных PDFпринтеров) для экспорта документов в PDF?»

Плохое требование 

Плохие вопросы

«Если дата события не указана, она выбирается автоматически».

«А если указана?»  «А если дату невозможно выбрать автоматически?» (Сам вопрос интересен, но без пояснения причин невозможности выбора) «А если у события нет даты?» (Тут автор вопроса, скорее всего, хотел уточнить, обязательно ли это поле для заполнения. Но из самого требования видно, что обязательно: если оно не заполнено человеком, его должен заполнить компьютер.) 

Хорошие вопросы

«Возможно, имелось в виду, что дата генерируется автоматически, а не выбирается? Если да, то по какому алгоритму она генерируется? Если нет, то из какого набора выбирается дата и как генерируется этот набор? Возможно, стоит использовать текущую дату?»

2.  Тест-кейсы и чек-листы.

• Продумывание тест - кейсов и чек - листов

Хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование.

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

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

Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть соседние требования, задать вопросы коллегам и т.д.). Анализ других требований позволит  лучше понять и это конкретное требование. Но если это не помогает — то требование нужно переработать.

• Исследование поведения системы

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

• Рисунки (графическое представление) 

Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т.д. 

Словесное описание базы данных может занимать несколько страниц. Графическое представление удобно своей наглядностью и краткостью.

На рисунке легко заметить, какие-то элементы «не стыкуются»,  где и чего не хватает и т.д. Если для графического представления требований использовать общепринятую нотацию (например, языка UML), можно получить  дополнительные преимущества:  схему смогут без труда понимать и дорабатывать коллеги, а в итоге может получиться хорошее дополнение к текстовой форме представления требований.

• Прототипирование

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