Документация, сопровождающая процесс верификации и тестирования (тест-требования)

10.2. Стратегия и планы верификации

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

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

Для каждого этапа определяется:

• типы входных и выходных документов;
• общая процедура верификации;
• роли и ответственности;
• форматы и соглашения по идентификации выходных документов;
• критерии оценки результативности этапа.

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

• план верификации системных требований;
• план верификации архитектуры;
• план тестирования программного кода;
• план тестирования модулей и их интеграции;
• план системного тестирования;
• план нагрузочного тестирования;
• план полунатурных испытаний;
• план приемо-сдаточных испытаний.

Согласно разделу 4 стандарта IEEE 829 [15] основная задача плана тестирования как документа - определение границ тестирования, подхода к тестированию, требуемых для тестирования ресурсов, плана-графика тестирования. План тестирования определяет тестируемые элементы и функции системы, задачи, решаемые в ходе тестирования, сотрудников, ответственных за тестирование, и риски, связанные с этим планом. Такая форма плана тестирования является достаточно полной и включает в себя не только технические аспекты, связанные собственно с описанием тестовых примеров, но и организационные, связанные с общим управлением процессом тестирования. На практике объемы технических и организационных разделов планов тестирования могут достаточно сильно варьироваться. Однако, минимально необходимые элементы, которые рекомендуется включать в каждый план тестирования - это:

• идентификатор плана тестирования и номер его версии, который позволяет однозначно находить нужный план тестирования и его последнюю актуальную версию в базе данных проекта;
• общее описание тест-плана ;
• трассировка на другие документы - стандарты, планы тестирования, тест-требования, результаты выполнения тестов;
• определение тестируемых областей системы - указание частей проектной документации, исходных текстов, исполняемого кода, подвергаемых верификации с указанием типа верификации (автоматизированные тесты, формальные инспекции, тестирование на моделях, полунатурные испытания и т.п.);
• определение подходов к тестированию - определение общих методик, которых следует придерживаться при тестировании системы. Несмотря на то, что большинство тестов могут довольно сильно различаться, общие методы и подходы к их построению могут быть едиными;
• критерий успешности/неуспешности прохождения тестов (pass/fail criteria) - в данном разделе описывается то, каким образом определяется успешность прохождения тестов для различных частей системы;
• тестовые документы - как правило, план тестирования содержит в качестве приложений все тестовые документы более низких уровней - тест-требования, тест-планы, результаты выполнения тестов, данные о сборе покрытия. В случае, если включать эти документы в состав плана тестирования представляется нецелесообразным (например, в случае их значительного объема), рекомендуется помещать ссылки на эти документы;
• требования к среде тестирования - данный раздел описывает требования к аппаратным и программным средствам, необходимым для проведения тестирования. В случае встроенного программного обеспечения программная система обычно работает на специальном аппаратном обеспечении, а инструментальные средства для тестирования - на обычных PC общего назначения. Для выполнения тестирования в таких условиях требуется либо использование эмуляторов, либо программно-аппаратный комплекс для сопряжения специального аппаратного обеспечения с PC. Кроме того, как правило, в состав программных средств тестирования входят кросс-средства разработки. В случае, если тестируется система общего назначения, в данном разделе просто перечисляются требования к оборудованию, необходимому для тестирования, которые, как правило, несколько выше, чем требования к оборудованию, достаточному для работы системы;
• людские ресурсы и уровень их подготовки - в данном разделе приводится состав группы тестирования, необходимый для успешного завершения тестирования в поставленные сроки, а также приводится необходимые знания для различных ролей в группе;
• план-график тестирования - содержит сроки всех фаз тестирования;
• риски - содержит список рисков, которые могут помешать завершить тестирование в срок или с необходимым уровнем качества. Как правило, для каждого риска оценивается вероятность его возникновения, а также приводятся общие пути, при помощи которых можно избежать возникновения риска или ликвидировать его последствия

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

10.3. Тест-требования

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

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

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

Рис. 10.2. Место тест-требований среди проектной документации

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

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