1.13. Тест-требования
1.13.1. Технологические цепочки и роли участников проекта, использующих тест-требования. Связь тест-требований с другими типами проектной документации.
Тест-требования – основной документ для тестировщика, который определяет функциональность системы с точки зрения того, что должно быть проверено для того, чтобы удостовериться в ее корректном функционировании, а также – на основании какого внешнего эффекта можно убедиться, что проверяемая функция реализована правильно.
Существует два подхода к написанию тест-требований – функциональный и структурный. Тест-требования, написанные в рамках функционального подхода основываются на системных требованиях и требованиях к программному обеспечению системы.
Тест-требования, написанные в рамках структурного подхода пишутся на основании описания архитектуры системы и принимают в расчет строение исходных текстов системы. Из-за такого различия функциональный и структурный подходы часто называют подходами черного и белого ящиков. Структурные тест-требования важны в том случае, когда к надежности системы предъявляются повышенные требования. Т.е. когда важно проверить не только насколько корректно система в целом отрабатывает сценарии своей работы (корректные и некорректные с точки зрения пользователя), но и как в различных нестандартных ситуациях будут вести себя отдельные ее компоненты.
Рис. 1.14 Место тест-требований среди проектной документации
На практике почти всегда применяются оба подхода к разработке тест-требований, в результате в состав документации проекта включаются тест-требования верхнего уровня и тест-требования нижнего уровня, по которым составляются тест-планы (Рис. 1.14).
1.13.2. Свойства тест-требований
Как уже говорилось выше, тест-требования содержат описание требованиий по проверке всех основных функций системы. Тест-требования должны быть достаточными построения тест-плана проверки реализации задачи без знакомства с ее программными текстами, т.е. тест-требования должны обладать свойством изоляции от внутренней структуры системы.
Как правило, структура тест-требований следует структуре раздела функциональных требований на систему. Задача каждого требования - определение того, что надо проверить. Техника исполнения каждой такой проверки - задача тест-плана. Обычный формат описания отдельного требования следующий:
Проверить, что при <описание внешнего воздействия> [происходит] <описание реакции программы >.
Тест-требования, написанные в рамках функционального подхода обычно разделяют на следующие группы:
• функции контроля входных данных,
• функции обработки ошибок (ввода, вычислений),
• функции получения основного результата,
• функции обработки особых ситуаций,
• функции оформления и вывода результатов.
Конкретизация программной реализации может потребовать уточнений или расширений реакций на различные ситуации, возникающие при решении задачи. В этом случае рекомендуется оформить дополнительные тест-требования низкого уровня для структурной проверки системы.
Совокупность тест-требований должна обладать некоторыми важными свойствами: полнота, верифицируемость и непротиворечивость.
Как правило, одному системному или функциональному требованию соответствует минимум одно тест-требование. Если совокупность проверок, задаваемых тест-требованиями, покрывает всю функциональность системы, определенную в системных требования и требованиях к программному обеспечению, то говорят о полноте тест-требований. При изменениях требований к системе для поддержания полноты должны меняться и тест-требования.
Как системные требования и требования к ПО, так и тест-требования должны обладать свойством верифицируемости. Т.е. для каждого требования должна существовать возможность определить четкий критерий проверки – выполняется это требование в реализованной системе или нет.
Примером не верифицируемого требования может служить следующее «требование»:
Система должна иметь интуитивно понятный пользовательский интерфейс.
Очевидное «тест-требование» будет выглядеть как
Проверить, что система имеет интуитивно понятный пользовательский интерфейс
Без четкого определения критериев интуитивной понятности, проверить такое требование при помощи написания тестовых примеров не представляется возможным. Однако, если сопроводить такое требование количественными или качественными характеристиками интуитивно понятного интерфейса – написание тестовых примеров по требованиям становится возможным. Так, среди критериев интуитивной понятность могут быть следующие: глубина вложенности меню не более трех, наличие всплывающих подсказок на каждом элементе управления каждой экранной формы и т.п.
При большом количестве тест-требований и частых их изменениях может возникнуть ситуация, в которой различные требования перестают быть согласованными. В этом случае такие требования имеют взаимоисключающие друг друга критерии проверки. Т.е., например, в простом случае, одно тест-требование на пользовательский интерфейс может декларировать необходимость проверки того, что введенный пользователем пароль имеет длину не более 16 символов, а тест-требование к базе данных системы – что допустимый размер пароля, сохраняемого в БД – от 4 до 12 символов. В этом случае эти два требования являются противоречивыми. Для того, чтобы устранить это противоречие нужно проводить анализ системных и функциональных требований с последующей модификацией тест-требований. Тест-требования по которым составляются тест-планы для тестирования системы обычно обладают свойством непротиворечивости, поскольку противоречия обычно устраняются на уровне верификации проектной документации. Однако противоречия могут быть выявлены и позже, в результате попытки создать адекватные тестовые примеры.