Экспертные оценки

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

• дефектов, свойственная этому методу, меньше, чем эффективность двух других методов.

Врезка 2.2.

Критерии, используемые при тестировании требований

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

П о л н о т а. Набор требований считается полным, если все его составные частипредставлены и каждая такая часть выполнена в полном объеме. При тестировании набора требований на полноту необходимо обратить особое внимание на следующие моменты:

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

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

• Требование не должно ссылаться на функциональные средства, которые еще не определены.

50 Часть I. Процесс быстрого тестирования

Однозначность. Каждое требование должно быть точно и ясно сформулирова­но; оно должно допускать единственное толкование. Требование должно быть удобо­ читаемым и понятным. Если требование отличается особой сложностью, для облег­ чения понимания может быть привлечен вспомогательный материал, такой как, диа­ граммы или таблицы. Если для пущей убедительности используются выражения на­ подобие " это очевидно" или " само собой разумеется", то вполне возможно, что автор пытается отвлечь ваше внимание от того или иного двусмысленного утверждения.

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

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

Осуществимость. Каждое требование должно ставить перед системой задачуобеспечить такие средства, которые целесообразно разрабатывать и поддерживать. Если заказчик предъявляет к системе нереальные требования в смысле затрат време­ ни и средств на разработку тех или иных функций либо же требует разработки функ­ ций, которые окажутся ненадежными и опасными в эксплуатации, необходимо опре­ делить риски и принять соответствующие меры. По сути дела, разрабатываемая сис­ тема должна быть экономически осуществимой, надежной, удобной в эксплуатации и сопровождении.

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

Использование прототипов

В качестве дополнения к методам статического тестирования для проверки и под­ тверждения требований с большой пользой могут быть использованы прототипы программного продукта. Прототип (prototype), будь то макет на бумаге или модель про­ граммного продукта, дает вам возможность предложить заказчику варианты и полу­ чить обратную реакцию, которая позволяет сделать формулировки требований более точными. Прототипы часто позволяют выявить дефекты в полноте, непротиворечи-

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

Существуют два подхода к использованию прототипов. В рамках одного из них производится построение одноразового прототипа (throwaway prototype), который используется исключительно для определения требований; прототип не поставляет­ ся заказчику в виде программного продукта. Второй подход предусматривает созда­ ние эволюционного прототипа (evolutionary prototype), который применяется на на­ чальной стадии процесса для выявления и анализа требований, и в то же время под­ вергается многократным усовершенствованиям, постепенно превращаясь в продукт, который уже можно поставлять заказчику. Тестирование эволюционного прототипа программного продукта рассматривается в следующем разделе.

Один из способов встраивания прототипа в жизненный цикл разработки показан на рис. 2.6 [42]. В рамках этого подхода прототипы могут быть построены на стадии формулирования требований и на стадии проектирования цикла разработки. Прото­ типы используются во время анализа требований для уточнения и тестирования тре­ бований. На стадиях системного проектирования и проектирования программ раз­ работчики могут применять прототипы для оценки альтернативных стратегий про­ ектирования. Программный код, разработанный для прототипа, в такой модели раз­ работки может как использоваться, так и отбрасываться за ненадобностью.

Рис. 2.6. Прототипу добавленные в каскадную модель жизненного цикла. Взято из [42]; измерения внесены с разрешения издательства Prentice Hall