Системное и другие виды тестирования

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

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

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

Полезное правило. Позаботьтесь о том, чтобы бригада, выполняющая систем­ное тестирование, была подготовлена к работе с платформой и ее базовыми сти­лями ПИ.

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

Полезное правило. В процессе проведения системного тестирования привле­кайте небольшой коллектив пользователей для оценки ПО в течение более про­должительного времени.

Пользователи выполняют заранее определенные тестовые прецеденты, осуществ­ляют незапланированное тестирование и обеспечивают организованную обратную связь с проектной бригадой.

Трудности, решения и уроки

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

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

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

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

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

Полезное правило. Чем позже вы установите обратную связь с пользователя­ми, тем дороже вам это обойдется.

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

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

Полезное правило. Для осмысленного связывания знаний в проектной докумен­тации и прототипах полезно использовать гиперссылки.

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

Отделение ПИ от бизнес – логики. Обычно отделение программного обеспечения ПИ от бизнес - логики — непростая задача. Она выполнима, но за ней сто­ит дополнительное время проектирования и расходы на реализацию. Например, если бизнес – правила контролируют допустимость значений полей и вариантов выбора элементов меню, необходимо спроектировать и реализовать механизм решения этой задачи вне чистой логики ПИ.

Кроме того, создание ПО с разделением ПИ и бизнес - логики обладает преимуще­ством потенциально более независимой разработки и повторного использования программных компонент.

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

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

Продуктивность. К процессу конструирования применяются различные метрики. Ниже приведены примеры некоторых метрик, имеющих критическое зна­чение для отслеживания продвижения и успеха продукта.

• Навигационная структура между системой, экранами и справками реализована.

• Экраны и справки спроектированы и реализованы с использованием средств разработки.

• Поддержка помощи и эксплуатации спроектирована и реализована с исполь­зованием средств разработки.

• Пользовательские визуальные данные и методы реализованы.

• Частота дефектов и их серьезность лежат в допустимых пределах.

• Процент переделок невелик.

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

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

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

Полезное правило. Помните о необходимости передать ваши знания последо­вателям — заказчик уже заплатил за это.

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