Автоматизированное тестирование: оценка возврата инвестиций и сопутствующие риски
Некоторые цифры, связанные с проблемами разработки сложных систем
Александр Новичков и Вячеслав Панкратов — сотрудники компании «СМ-Консалт» (www.cmcons.com).
юбая информационная система (ИС) должна решать определенные задачи заказчика или клиента. Требования к функциональности, реализуемой в ИС, либо исходят непосредственно от заказчика, либо формализуются бизнес-аналитиками, которые участвуют в проекте по разработке ИС. Процессы реализации IT-проекта по разработке ИС направлены на оптимальное решение бизнес-задач заказчика, выраженных в виде формальных требований к разрабатываемому программному обеспечению.
Сегодня довольно много публикаций посвящено тому, как создаются информационные системы и реализуются проекты по разработке программного обеспечения. Авторы могут придерживаться различных методологий разработки, спорить о преимуществах того или иного подхода в планировании процессов либо документировании процедур, а также по поводу гибкости последних, однако общая схема создания информационных систем достаточно проста и, как правило, состоит из одних и тех же модулей и процессов:
- управление проектом в виде координации действий проектной команды, направленных на достижение целей проекта оптимальным путем;
- постановка задачи в виде определения требований и последующих работ с ними;
- управление изменениями в проекте, причем такие изменения могут касаться как самих требований к системе, так и организационной схемы процесса, а причиной этого могут быть либо требования заказчика (или бизнес-аналитика), либо обнаруженные в ИС дефекты;
- разработка ПО как непосредственное кодирование программной реализации функциональных требований и проектирование схем хранения и движения информации в ИС;
- тестирование ПО как процесс, решающий задачу верификации соответствия требований, выдвинутых к ИС, и их программной реализации;
- эксплуатация ПО как сумма задач по обеспечению технической и технологической поддержки процесса работы ИС, включая поддержку и необходимое системное администрирование.
Как видите, процесс разработки ИС состоит из нескольких взаимозависимых модулей, которыми и оперируют авторы методологий и подходов, изменяя приоритеты между направлениями или соединяя задачи нескольких направлений (предлагая, к примеру, осуществление задач тестирования в рамках деятельности по непосредственной разработке программной реализации и т.д.). Однако суть остается прежней — имеется технологическая цепочка процессов разработки информационных систем, модули которой взаимозависимы и не могут функционировать в отрыве друг от друга.
Рассмотрим более подробно процесс тестирования как составляющую общего процесса обеспечения качества разработки ПО. Входной информацией для процесса тестирования являются, во-первых, данные о задачах, решаемых с помощью программной реализации (эти данные образуются в результате формулировки требований), а во-вторых, уведомления об изменениях (эти уведомления создаются в результате процесса управления изменениями). Процесс тестирования решает задачу верификации указанных требований в программной реализации, предоставляя информацию о состоянии продукта, на основе которой принимается решение о критериях завершения этапа разработки (а в некоторых случаях также решая задачу непосредственного выпуска версии системы). Таким образом, тестирование как процесс тесно связано с другими процессами проекта, использует информацию, полученную от них, и, в свою очередь, является источником информации для процесса управления проектом. Казалось бы, это очевидно, однако многие проекты по внедрению методологий разработки или по внедрению процессов (управление требованиями, автоматизация тестирования и т.д.) ограничиваются решением частных задач путем внедрения в эксплуатацию отдельных частей методологий или посредством применения инструментальных решений, не позволяющих связать процесс тестирования с другими процессами проекта в силу отсутствия внутренней интеграции (к примеру, решений различных производителей) и привязки к единому процессу. Как показывает статистика внедрения решений и анализ успешности крупных IT-проектов, попытки решить задачу проекта по разработке информационной системы с помощью выделения и развития одного из направлений с большой долей вероятности обречены на провал.
|
Некоторые цифры, связанные с проблемами разработки сложных систем:
|
||
Так, иногда предпринимаются попытки повысить качество продукта в проекте с низким уровнем формализации и при отсутствии процедур работы с требованиями — только за счет внедрения инструментов автоматизированного тестирования. Однако без четких процедур работы с требованиями и без формализованных и инструментально обеспеченных процессов внесения и отслеживания изменений никакие инвестиции в тестирование не окупаются, что вызывает, даже в условиях применения мощнейших решений и достаточно гибких методологий, негативную реакцию заказчиков и искаженное представление о возможностях методик, инструментов и решений. Чтобы избежать подобных сложностей при внедрении изменений в методику и порядок работ, перед внедрением инструментальных решений и перестройкой внутренних технологических процессов необходимо проводить анализ применимости тех или иных решений и подходов с точки зрения системности вносимых изменений и внутренних взаимосвязей технологических процессов разработки информационных систем.
Распространено заблуждение, что тестирование — это заключительная часть разработки ПО. Однако когда продукт уже готов и в нем обнаружены такие серьезные ошибки, как несоответствие первоначальным требованиям к функциональности, то в большинстве случаев исправить их можно только одним способом — значительно изменить или даже переделать уже законченный программный комплекс. Это требует неоправданно высоких временных, денежных и трудовых затрат. Чем позже будет обнаружен дефект или логическое несоответствие в функциональности ИС, тем больший объем реализованной функциональности и логики совместной работы модулей потребует переделок. Поэтому основной принцип тестирования — начинать как можно раньше, внедряя практики верификации не только по отношению к программной реализации требований, но и к формализованным в виде требований описаниям нужной функциональности. Как показывает опыт крупных компаний, разрабатывающих решения для промышленной эксплуатации, верификации подлежат также технологические решения, принимаемые в процессе создания архитектуры информационной системы (рис. 1). Обратите внимание, что процесс тестирования начинается даже несколько раньше, чем процесс разработки, что характерно для правильного подхода.
Рис. 1. Процессы и стадии жизненного цикла в Rational Unified Process
Последствиями слабо формализованного или вообще не работающего процесса тестирования являются прямые финансовые потери вследствие сбоя или простоя продуктивных систем, а также перерасход ресурсов и средств в процессе разработки проектов. Во вторую группу последствий входят риски не столько заказчика, сколько проекта в целом, а значит, и заказчика, и исполнителя. Современные программные системы обеспечения жизнеспособности бизнеса по стоимости могут превышать вложения в материальные активы, а проекты по разработке ПО часто относятся к критической группе вложений средств компаний. Единственным источником актуальной информации о ходе таких крупных проектов было и остается тестирование, результатами которого являются метрики качества создаваемого продукта и успешности проекта в целом.
Особое значение при разработке крупных систем приобретает технология автоматизированного тестирования, поскольку она позволяет автоматизировать большой объем работ по тестированию и, следовательно, обеспечить требуемый уровень качества разрабатываемого программного средства. Проекты по разработке сложных программных систем характеризуются большим объемом вносимых в структуру ПО изменений, которые порождаются работами по дополнительному тестированию ранее проверенной функциональности. Регрессионное тестирование, как процесс, обеспечивающий проверку существующей функциональности продукта после внесения изменений, в системах с продолжительным сроком разработки и большим объемом функциональности, характеризуется ресурсоемкостью, затратностью и продолжительностью, но вместе с тем оно является технологически необходимым видом работ и приоритетным для автоматизации. Автоматизация утомительных, часто повторяющихся и трудновоспроизводимых операций — одно из наиболее целесообразных вложений при комплексной автоматизации тестирования.
Примерами вышеуказанных операций могут служить:
- написание текстов сценариев тестирования, которые при автоматизированном тестировании создаются автоматически в процессе наблюдений за работой пользователя или путем диалога с пользователем;
- запоминание результатов тестирования, тогда как при автоматизированном тестировании они сохраняются в базах данных (с указанием условий тестирования, параметров операционной среды и т.д.) и тем самым становятся доступными для дальнейшего анализа;
- подготовка тестовых данных, автоматически формирующихся при автоматизированном тестировании либо в ходе тестирования, либо перед его началом; при этом пользователь может описать несколько законов, на основе которых такие данные будут создаваться;
- запуск тестов в определенной последовательности с определенными тестовыми данными, но в случае автоматизации выполнение тестов может происходить в пакетном режиме в заранее определенное время;
- одновременная работа нескольких пользователей, которая при автоматизированном тестировании имитируется на программном уровне; для управления процессом нужен всего один, а не десятки или сотни пользователей, как при ручном тестировании).
Для того чтобы обеспечить надлежащий уровень качества разрабатываемого программного средства, необходимо применять современные высокоэффективные методы, технологии и средства проектирования, разработки, сопровождения и развития ПО. Кроме аспектов целесообразности тестирования в процессе разработки ИС и рисков IT-проектов, описанных выше, рассмотрим результаты расчетов инвестирования в автоматизированное тестирование.
Начнем с вопроса о возврате инвестиций. Опыт свидетельствует, что внедрение практик и средств нагрузочного тестирования позволяет получать, кроме непосредственных прямых выгод, связанных с экономией средств на поддержку и сопровождение продуктивных систем, также и выгоды за счет покрытых этим видом тестирования рисков недополучения прибыли.
Какие же факторы влияют на объемы средств автоматизированного нагрузочного тестирования? Все факторы можно разделить на две группы — это факторы, вызывающие прямую экономию средств, и факторы, снижающие риск понесения убытков.
Основными пунктами экономии являются:
1. Экономия средств на реализацию излишней надежности продукта.
Расходы объясняются затратами на реализацию излишней функциональности, рассчитанной на выполнение явно завышенных (порой даже в несколько раз) требований к производительности, или на излишнюю оптимизацию архитектуры и кода, что увеличивает сроки разработки и тестирования, а следовательно, повышает стоимость проекта в целом.
2. Экономия на вложениях в реализацию излишней надежности инфраструктуры.
Данные расходы по своему характеру и по причинам возникновения схожи с описанными выше и возникают из-за недостаточной информации о возможностях применяемых технологий и об усредненных (или сознательно завышенных, то есть пессимистических) результатах эмпирических прогнозов. Последствия этого выражаются в затратах на анализ и реализацию излишней надежности инфраструктуры, механизмов дублирования логики и дорогостоящих решений по агрегации и миграции данных.
3. Экономия времени и средств на выявление и устранение неисправностей во время эксплуатации.
Сюда относятся статьи расходов служб эксплуатации и контроля, а также системного администрирования на локализацию и выявление причин сбоев, на восстановление систем до работоспособного состояния, а также на проведение работ по восстановлению данных и состояния продуктивных систем.
Указанные затраты могут превращаться в серьезную статью расходов в случае аутсорсинга IT-задач и сервисов за рамки компании, которая использует информационную систему для решения своих бизнес-задач.
Основные риски, которые покрываются за счет проведения нагрузочного тестирования, таковы:
1. Недополучение прибыли вследствие простоя или низкой производительности продукта.
Этот риск особенно актуален для современных систем онлайновой торговли, обработки заказов, формирования пакетов доставки и транспортной логистики.
2. Необратимые логические сбои в структурах хранения данных в результате несвоевременных обновлений данных или усложненных запросов на получение актуальной информации.
Особую актуальность данный риск приобретает в условиях большого объема обрабатываемых современными системами данных и большого количества выполняемых за единицу времени операций.
Критичен этот риск и для систем оперативного контроля и мониторинга, систем, работающих в режиме реального времени, систем автоматизированного управления агрегатами и аппаратами, а также для систем жизнеобеспечения.
3. Необратимые изменения или потеря операционных данных из-за программного сбоя, вызванного избыточными нагрузками.
Риск актуален в сфере хранения и обработки финансовой информации, которая носит уникальный характер, не может быть восстановлена на основе эмпирических допущений и несет прямую угрозу финансовых убытков. Кроме финансовых систем, это представляет опасность для проектов биллинга и регистрации процессинговой информации.
4. Необратимые изменения или потеря операционных данных вследствие аппаратного сбоя, вызванного нагрузками.
Данный риск актуален не столько из-за угроз реальных потерь данных, сколько за счет затрат времени, которое требуется на восстановление информации. Если информация не может быть восстановлена или зарегистрирована в системе в результате сбоя, риск становится критичным.
А теперь приведем результаты практических расчетов возврата инвестиций в автоматизированное функциональное тестирование, которые учитывают затраты на приобретение инструмента, обучение персонала, а также реальную специфику современных проектов по разработке информационных систем, характеризующихся большим количеством уточняемых и меняющихся изменений. Таким образом, здесь учтены затраты не только на создание необходимых автоматизированных сценариев, но также на поддержку набора тестов в актуальном состоянии.
Расчеты проводились для проекта по автоматизации функционального тестирования. Мы выбрали проект, объем работ по тестированию в котором измеряется десятками тысяч тестовых прогонов за время разработки и составляет 65 тыс. тестовых операций в год. Стоимость часа работы специалиста по тестированию установлена в размере 30 долл. в час, а затраты на лицензии к программному обеспечению автоматизации тестирования и обучение персонала установлены в 75 тыс. долл. На рис. 2 и 3 представлены соответственно денежные и временные затраты при ручном и автоматизированном проектировании. Как видно, затраты средств на ручное тестирование растут значительно быстрее, чем затраты на автоматизацию тестирования с ростом функциональности системы. Рост временных затрат в данном примере сравним с ростом денежных затрат. Хотя ситуация может незначительно меняться от проекта к проекту, однако общая тенденция сохраняется.
Рис. 2. Сравнение затрат денежных средств на ручное
и автоматизированное тестирование
Рис. 3. Сравнение временных затрат при ручном
и автоматизированном тестировании
Практика внедрения средств автоматизированного тестирования в большие софтверные проекты показывает, что это позволяет добиться в десятки раз более полного покрытия функций ИС, чем ручное тестирование. Основываясь в наших расчетах на пессимистических прогнозах и выбирая данный коэффициент равным пяти, мы получаем оценки, которые позволяют говорить, что время, затраченное на автоматизированное тестирование, в семь раз меньше суммарного времени, затрачиваемого на ручное тестирование. А включая первоначальные расходы времени на обучение, получаем рост показателей производительности в семь раз, что подтверждается приведенным графиком расчетов временных затрат. Экономический эффект достигается вследствие экономии ресурсов, затраченных на многократное выполнение набора тестовых сценариев, и составляет при цикле жизни приложения около трех лет от 20 до 45%, что показывает график сравнения стоимости ручного и автоматизированного тестирования (см. рис. 2 и 3).
Примерами систем, в отношении которых может быть выгодна автоматизация функционального и нагрузочного тестирования, могут служить современные системы биллинга абонентов. Например, для энергетической отрасли, газовых и телекоммуникационных компаний и других предприятий, которые работают с большой базой клиентов и бизнес которых связан с изменениями в законодательстве и с конкурентными изменениями на рынке. Отдельно стоит выделить системы автоматизации крупных развивающихся предприятий, зависящих от ситуации на рынке и от состояния дел в области прикладных наук. Это яркие примеры систем, которые непрерывно и динамично развиваются, требуют постоянных изменений, часто затрагивающих основные бизнес-процессы, заложенные в качестве базовых архитектурных и алгоритмических решений.
