Шрифт:
(Воспроизводится с разрешения Центрального секретариата МОС с веб-сайта Международной организации стандартизации www.iso.org.)
Более подходящее определение тестирования программного обеспечения:
Процесс планирования, подготовки, исполнения и анализа, направленный на установление характеристик информационной системы и выявление разницы между фактическим и требуемым состоянием.
{57}Тестирование имеет особое значение в ситуации фундаментальных или крупномасштабных изменений, а не для краткосрочных или небольших разработок. Поэтому тестирование – важнейшая процедура, которая должна быть тщательно и разумно спланирована; ее нельзя отодвигать на слишком позднюю стадию проекта. План и программа тестирования должны быть выполнены в деталях при составлении бизнес– и функциональных спецификаций. Если сценарии тестирования и программы-скрипты составлены на данной стадии, это даст бизнесу и разработчикам более четкое понимание требований бизнеса. Будет понятна база, по которой произойдет оценка системы, что должно еще больше снизить риски, связанные с недопониманием между требованиями бизнеса и продуктами разработчиков.
Требуют учета следующие весьма серьезные аспекты:
• важно помнить, что на подготовку и планирование нужно отвести более половины всего времени тестирования, а остальную часть – на фактическое проведение тестов;
• почти невозможно и весьма нежелательно выполнять 100-процентное тестирование, поскольку затраты и сроки будут нереальны. Лучше практиковать структурированный подход, добиваясь максимума эффективности при минимуме усилий. Руководитель тестирования должен всегда определять глубину тестирования, количество ошибок и «объем тестов».
Можно выделить следующие типы тестирования {57}:
• тест блока выполняется разработчиками в лабораторных условиях и должен показать, что данная работа или шаг автоматизированного решения BPM отвечает требованиям, сформулированным в техническом задании;
• тест интеграции выполняется разработчиками в лабораторных условиях и должен показать, что данная функция или аспект автоматизированного решения BPM отвечает требованиям, сформулированным в техническом задании;
• системный тест выполняется разработчиками в (надлежаще контролируемых) лабораторных условиях и должен показать, что автоматизированное решение BPM или его компоненты отвечают требованиям, сформулированным в функциональных спецификациях и требованиях к качеству;
• тест функциональной приемки (FAT) выполняется системным менеджером и группой тестирования в условиях, в максимально возможной степени имитирующих эксплуатационную среду. Он должен показать, что автоматизированное решение BPM отвечает требованиям к функциональности и качеству, сформулированным в функциональных требованиях;
• тест приемки пользователями (UAT) выполняется пользователями системы. В «теневых» эксплуатационных условиях автоматизированное решение BPM будет испытано на предмет соответствия требованиям бизнеса. Это включено в этап реализации;
• регрессионный тест предназначен показать, что все части системы по-прежнему функционируют правильно после внедрения или модификации автоматизированного решения BPM. Регрессия – это явление, показывающее, что качество системы как целого не ухудшается в результате отдельных модификаций.
Разумеется, нужно следовать обычному процессу тестирования:
1. Определите показатели теста. Тестирование всегда предполагает баланс между выгодами от тестирования и связанными с ним затратами. 100-процентное тестирование – практически нереальное и чрезвычайно дорогостоящее мероприятие. TMap® – прагматичный подход, описанный в {57}.
2. Определите и опишите стратегию тестирования, которая должна включать тест блоков, приемки пользователями (UAT), интеграции, регрессионный тест и т. д. Необходимо обдумать используемую инфраструктуру. Замечание: обязательно сделайте все возможное в рамках проекта, чтобы на стадии тестирования использовалась точная копия действующей среды инфраструктуры. Многие проекты развалились, если данное условие не было выполнено. Также помните, что не все тесты относятся к системам приложений. В процессной среде бо льшая часть тестирования вращается вокруг «пробных прогонов» процессов в бизнес-подразделении и определения его пригодности для заданной цели.
3. Составьте план тестов. Организация принимает решение о количестве и типах тестовых конфигураций. Не забудьте привлечь все соответствующие заинтересованные стороны и другие подгруппы проекта.
4. Опишите различные конфигурации тестов. Объем их будет зависеть от размера и сложности проекта. Самое важное – охватить все вероятные сценарии.
5. Выполните тестирование. Завершите конфигурации и программы тестов.
6. Проанализируйте результаты и решите, как двигаться дальше. Варианты: продолжать реализацию, приостановить внедрение, пока не устранены ошибки, продолжить внедрение и обеспечить внесение изменений по ходу или же скомбинировать три этих варианта.
Не все тесты фактически выполняются на данном этапе, но их нужно обязательно предусмотреть. Например, примененные тесты пользователей подготавливаются и осуществляются как часть шагов 3 и 5 этапа реализации.
Реализация ценности
Чтобы добиться согласия, необходимо тщательно определить выигрыши как часть данного этапа. Подробности описаны в главе 21, шаг 5, в связи с реализацией ценности в проекте.