Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Валидация требований

Содержание

• Валидация требований

• Методы

• Планы тестирования

• Контрольные списки

• Инспекция

• Техническая поддержка

• Специфика CMMI

Валидация требований

«Валидация гарантирует, что требования отвечают желаемым характеристикам правильно поставленных требований (полнота, правильность, возможность, необходимость, приоритеты, однозначность и проверяемость), а также правильной спецификации требований (полнота, последовательность, модифицируемость и трассируемость)» – Software requirements second edition, Karl E. Wiegers.

Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика. Валидация помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют » Test-First Development » или » Requirements-Based Testing «. С валидацией участник проекта устанавливает критерии приемки для достижения соглашения с заинтересованными лицами о том, что будет поставлено. Это включает в себя проверку бизнес-требований, функциональных требований, нефункциональных требований, сценариев использования, моделей, прототипов и т.д.

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

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

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

Примечание: руководство по проверке требований, описанное в этом разделе предполагает, что требование на бизнес-уровне, реализуются рабочим элементом «Feature» в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Feature» для этой цели и признают, что это добавляет элемент формальности, который можно не использовать для более гибкой команды.

Методы

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

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

V-модель является промышленным стандартом для создания модели управления тестированием на всех уровнях жизненного цикла разработки приложений. Эти принципы могут быть реализованы в водопаде или в любом варианте итеративной разработки.

Рисунок 1. V-модель для управления тестированием

При разработке каждого уровня требований, которые находятся по левую сторону, правила валидации с использованием методов, описанных выше, будут помогать в разработке тестов, которые будут использоваться для проверки после поставки приложения, компоненты или системы. Лучшие процессы, которым нужно следовать – это «Test First Development» или «Requirements-Based Testing», где составляющая часть не рассматривается как готовая, пока определенные тесты не выполняются и не проходят успешно.

Итак, на основе V-модели описанной выше, следующий сценарий может быть применен на этапах развития всех описанных элементов:

• Определено бизнес-требования, но оно не готово для анализа на функциональные и нефункциональные требований, пока его приемочные тесты не будут установлены и подтверждены. Определите пользовательские приемосдаточные тесты (User Acceptance Test Cases) и свяжите с требованием Возможность (Feature Requirement).
  • Откройте форму Возможность (Feature) в проекте Team Foundation Server. Перейдите на вкладку Links, чтобы увидеть дочерние пользовательские истории (если вы откроете Возможность из шаблона процесса MSF Agile).
    
  • Из меню Team или панели инструментов на вкладке Links выберите Add New Linked Work Item …. В появившемся диалоговом окне выберите тип связи Tested by и рабочий элемент Test Case. Затем добавьте название для нового рабочего элемента. Можно также добавить комментарий.
    
  • Новый рабочий элемент позволяет тестировщику планировать, разрабатывать и вести вместе с разработкой модель тестирования для проекта разработки. На вкладке Steps пользователь может определить шаги для выполнения ручного тестирования. Мы не будем показывать это здесь, но этот рабочий элемент, при открытии в клиенте Microsoft Test and Lab Manager, позволяет запускать приложения для тестирования с просмотром этих шагов и отмечать успех или неудачу для каждого шага, а также наблюдаемых результатов (которые можно включать в стек вызовов!).
    
  • Поле Summary Task такое же, как и поле описания любого другого рабочего элемента. Здесь вводится высокоуровневое описание ожидания заказчика. Можно задать следующий вопрос заказчику, для того, чтоб быть уверенными, что заказчика правильно поняли: «Если будет сделана эта функция, что покажет, что она сделана правильно?» Ответ клиента, с небольшой доработкой аналитика, должен быть главным описанием процедуры приемочного теста.
  • Вкладка Tested Work Items отображает ссылку на Возможность (Feature), которая была только что связана:
    
  • Сохраните рабочий элемент, а затем дважды щелкните на Возможности (Feature) и выберите ее вкладку связей, чтобы увидеть новый тестовый сценарий связанный с ней.
    
• Требования к функционалу и качеству обслуживания не могут быть переданы дизайнерам и архитекторам, пока их тестовые сценарии не определены (не обязательно записаны) и не утверждены. Опишите высокоуровневые шаги тестового сценария
  • Открыть дочернее требование одного из рабочих элементов возможности. Это будет рабочий элемент либо Требование (Requirement) или Пользовательская история (User Story), в зависимости от используемого шаблона процесса. Выберите вкладку Test Cases, чтобы начать определение тестов. Выберите Add New Linked Work Item … как показано в окне ниже.
    
  • В появившемся диалоговом окне введите название для нового сценария тестирования. Только один вариант доступен как тип ссылки Tested By и тип рабочего элемента Тестовый сценарий (Test Case), поэтому никаких других атрибутов выбирать не нужно.
    
  • Результирующий рабочий элемент, как и в предыдущий процедуре, связывается с пользовательской историей, также как тестовый сценарий связывается с возможностью. Есть одно концептуальное отличие. Тестовый сценарий связанный с возможностью является Пользовательским приемочным тестом (User Acceptance Test case), а тестовый сценарий связанный с рабочим элементом системного требования является Системным тестом (System Test case).
• Разработка приложения не может быть передана разработчикам, пока каждый компонент не имеет интеграционных тестов и тесты по методу «черный ящик» не определены и не утверждены.
  • разработчик может разрабатывать связанные модульные тесты для его кода с целью написания тестируемого кода
• Код должен пройти весь набор написанных модульных тестов, прежде чем мы перейдем в правую часть модели.
• После того, модульные тесты проходят, компонент, который инкапсулируется протестированным кодом, может быть протестирован. Мы можем сделать это эффективно, поскольку интеграционные тесты и тесты по методу «черного ящика» были определены в ходе разработки.
• Как только интеграционные и тесты по методу «черного ящика» проходят, системные функциональные и нефункциональные тесты могут быть выполнены. Опять же, мы можем сделать это эффективно, потому что функциональные и нефункциональные тесты были определены и утверждены в рамках спецификации требований. Т.к. ранее были описаны функциональные шаги для каждого рабочего элемента тестового сценария, мы можем просматривать их и создавать тестовые комплекты в клиенте Visual Studio Test and Lab Manager.
  
• Далее, как только системные тесты проходят, не нужно ожидать пользовательских приемочных тестов, потому что они уже определены и утверждены во время спецификации бизнес-требований.
  • Пользовательские приемочные тесты могут быть организованы в тестовые комплекты в Visual Studio Test and Lab Manager.

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

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

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

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

Ожидаемо, что требования, принятые для декомпозиции и анализа, могут быть неоднозначны на этом уровне в плане того, как они будут детализированы.

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

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

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

Модель, показанная ниже, отображает структуру Team Foundation Server, которая поддерживается V-моделью, описанной на предыдущем рисунке. Как видно, Возможность (Feature или бизнес-требование) используется как дополнение к тесту, определенного в тестовом проекте в Visual Studio. Team Foundation Server позволяет пользователю установить связь между рабочим элементом и тестом в тестовом проекте. Более тесная интеграция устанавливается, когда инженер-тестировщик регистрирует изменения проекта тестирования в системе контроля версий. При регистрации изменений, связывание рабочего элемента с набором изменений может быть выполнено в принудительном режиме с использованием политик регистрации Team Foundation Server.

Аналогичный механизм Team Foundation Server поддерживается для Сценариев (Scenario, функциональные) или QoS (качество обслуживания или нефункциональные) требования.

Когда речь идет о разработке кода, это руководство показывает задачи для каждой из многих частей, которые должны быть реализованы для поддержки отдельного требования. Основываясь на этом методе, связь один-к-одном может быть установлена между небольшими блоками разработки и их тестами, которые связанны с одной задачей. В разделе Трассировки требований будет описано подробно об особенностях связей и отчетов, которые могут быть на основе них созданы.

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

Контрольные списки

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

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

• Product Acceptance Checklist – используется в качестве вехи для проверки, что все требования были охвачены необходимой документацией, дизайном, кодом, тестом и других критичными необходимыми артефактами.
• Requirements Review Checklist – используется в качестве руководства при рецензировании спецификации бизнес-требований, спецификации функциональных требований или спецификации технических требований. Оно проверяет, что стандарты документации были соблюдены и требования правильно сформированы (как описано выше).
• Requirements Style Checklist – по аналогии с предыдущим.
• Use Case Review Checklist – Используется для обзора требований сценария и его детального описания, которое должно включать в себя все шаги потоков, графические изображения для них и любые дополнительные сопроводительные данные. В тот же список применяется для пользовательских историй гибких проектов или традиционных функциональных требований.
• High Level Design Review – Используется для проверки, что реализуемые требования на высоком уровне отвечают выбранной архитектуре.
• Acceptance Test Planning, Results, Change Requests, WBS и другие списки покрывают другие требования и обязанности для проекта.

Обратите внимание, что даже присутствует список » Checklist for a Checklist » в этом пакете.

Используйте шаблон документа «Non-Functional Requirements Template» в качестве контрольного листа для выявления и проверки качества обслуживания (производительности, масштабируемости, бизнес-цикла, обслуживания, поддержки, размещения и т.д.).

Инспекция

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

Хороший процесс выполнения инспекций приведен ниже:

1. Отправлять материалы, которые будут рассмотрены, независимо для каждого рецензента.
2. Укажите, что каждый рецензент должен анализировать при инспектировании составляющих. Например, тестер должен определить тестируемость составляющих. То есть, могут ли быть тесты написаны и выполнены по завершению. Скажите им внести в документацию пометки, комментарии и критические замечания. Если они находят ошибки, они должны быть готовы для определения альтернативы по этой ошибке.
3. Наметьте встречи, выделяя участникам достаточно времени для ознакомления с материалом. Неделю, как правило, достаточно времени для этого.
4. Рассматривайте только те проблемы, которые были определены. Таким образом, совещания эффективно обеспечат, что рецензии будут завершены без потерь чьего-либо времени. Важно отметить, что рецензирование требований или инспекция это не мозговой штурм и сессия генерации идей. Объясните участникам важность их готовности.
5. Документируйте любые расхождения и определите задачи для авторов на исправление и повторное внесение на инспекцию.

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

Техническая поддержка

Используйте Team Foundation Server для поддержки вышеуказанных действий. Используйте Team Foundation Server для хранения результатов инспекций и принятия рецензий требований. Рассмотрите раздел Выявление для ознакомления с библиотекой документов Team Foundation Server, где хранятся контрольные списки и конечные продукты.

Специфика CMMI

«Анализируйте требования для определения риска связанного с тем, что конечный продукт не будет работать правильно в его предполагаемой среде использования» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

04.07.2010

Комментарии

• kFymdxJQmLWpJtXQtsZ
  Автор: Thank you so much for this atircle, it saved me time!  ·  18.03.2012 09:35:45
  Thank you so much for this atircle, it saved me time!
• tojeTeTVNKyvhJSqsV
  Автор: Essays like this are so important to brodaennig people's horizons.  ·  15.03.2012 09:52:53
  Essays like this are so important to brodaennig people's horizons.
• levitra
  Автор:   ·  05.12.2011 07:49:56
  who watched the Oscars?
• lUpWnHzSlaUTsxJ
  Автор: It's really great that people are sharing this inorfamtoin.  ·  20.08.2011 17:20:53
  It's really great that people are sharing this inorfamtoin.
• BsChZQaypG
  Автор: Oh yeah, fabluuos stuff there you!  ·  19.08.2011 05:07:11
  Oh yeah, fabluuos stuff there you!
• 
  Автор:   ·  19.07.2011 12:13:22
  Don't you acknowledge that it is the best time to receive the home loans, which would make you dreams real.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"