Русский   |   English
Instream
 


Эффективность использования автоматических тестов в ИТ-проектах

Abstract (Russian)

 

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

 

Keywords: Автотест; автоматизированное тестирование; экономическая эффективность

 


1.      Введение

 

ИТ-система слишком сложна и неповоротлива? Бесконечные итерации тестирования съедают бюджет ИТ-проекта? Время на поиск и исправление дефектов превысило все разумные пределы? Казалось бы, самое время внедрять автоматизированное тестирование. Но окупится ли оно? Стоит ли тратить время на автоматизирование тестирования или можно его потратить на более "насущные" проблемы?

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

В некоторых компаниях наоборот, обязательное применение автотестов закреплено внутренним процессом как дань моде и не всегда оправдано.

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

 

2.      Почему автоматическое тестирование может быть выгодно?

 

·         Стоимость

o        Значительное снижение трудозатрат на регрессионное, нагрузочное, юнит- и комплексное тестирование

o        Минимальное время на каждую итерацию тестирования после исправления ошибок

o        Автоматическое формирование отчётов о тестировании

o        Один тестировщик может параллельно осуществлять тестирование нескольких систем

o        Автоматические тесты могут выполняться в нерабочее время (ночь, выходные), что позволяет более рационально использовать время проектной команды и планировать тестирование.

·         Качество

o        Практически отсутствует человеческий фактор, если тесты покрывают функциональность полностью – пропуск ошибок в данной части практически исключен.

o        Возможно проводить больше итераций тестирования в единицу времени, чем при ручном тестировании

o        Если система слишком сложная, автотестами покрывается большая часть тестовых случаев, чем ручным тестированием.

o        Набор тестов ограничивается в первую очередь производительностью системы, а не доступным резервом времени тестировщиков

 

Нельзя упускать и психологический аспект автоматизированного тестирования. Не секрет, что во многих ИТ-компаниях, тестировщики «официально» ставятся ниже разработчиков, как по престижу, так и по тарифной сетке ЗП. С точки зрения построения эффективных проектных команд это совершенно неправильно, т.к. тестировщики, вместо того, чтобы развиваться в профессиональном плане, стремятся переквалифицироваться в разработчики, что значительно снижает  боеспособность подразделений тестирования компании (и практически не даёт компании новых профессиональных разработчиков). Как показывает практика, большой процент тестировщиков, которые «мечтают» быть разработчиками, слабо мотивированы на качественное ручное тестирование (держать ситуацию в руках обычно помогает контроль и карательные меры). Участие в создании автотестов даёт таким сотрудникам  вполне адекватное ощущение креатива и повышает заинтересованность и мотивацию в обеспечении качества проектов.

 

3.      Почему автоматическое тестирование может быть не выгодно?

 

·         Неправильно оценён масштаб возможного покрытия системы автотестами. Например, при попытке автоматизации того, что не должно быть автоматизировано (слишком дорого для автоматизации).

·         Сотрудники не имеют достаточной квалификации. В таком случае, срок завершения автоматизированных тестов – вечность.

·         Автотесты не могут быть использованы в дальнейшем. Ни в коем случае нельзя писать автотесты «в стол». Если в будущем (в будущих проектах или на следующем этапе) невозможно их повторное применение – лучше отказаться от написания автотестов в пользу ручного тестирования (за исключением очень сложных функциональностей, которые кроме как автотестами никак и не проверить).

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

 

4.      Эффективность использования автотестов

 

Бытует мнение, что выгода от использования автоматических тестов ограничивается 2-10% от бюджета ИТ проекта. Это действительно так. Но только при неправильной стратегии использования автотестов.

Факторами, наиболее сильно влияющими на экономическую эффективность использования автотестов являются:

·         Тип тестируемой системы

·         Процент покрытия автотестами

·         Стадия тестирования, на которой применяются автотесты

·         Технология/инструмент тестирования

 

4.1.            Тип тестируемой системы

 

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

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

·         Системы, имеющие сложный GUI (CRM, ERP, Self-care, Личные кабинеты). Для таких систем характерно:

o        GUI может сильно модифицироваться от версии к версии, что повлечёт за собой каскадное изменение автотестов, что связано с дополнительными затратами.

o        Инициатором возникновения ошибок работы является пользователь, поведение которого затруднительно смоделировать при помощи автоматических тестов.

o        Эргономику подобных решений невозможно проверять автоматически.

·         Offline расчётные системы (биллинг,  системы интеллектуальной рассылки, аналитические системы, отчётность):

o        Расчётная часть очень хорошо подвергаются автоматизированному тестированию в силу большой однозначности результатов и критериев оценки корректности работы.

o        Большое количество обрабатываемых данных и сложная логика. Большой объём и длительность выполнения автотестов.

o        Протестировать весь функционал вручную затруднительно.

·         Online транзакционные системы (online-тарфикация, gateway)

o        Много мелких операций

o        Наиболее удобны для применения автотестов из-за чёткой дискретизации производимых операций

o        Время выполнения автотестов минимально.

 

4.2.            Процент покрытия автотестами

 

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

 

4.3.            Стадия тестирования, на которой применяются автотесты

 

Целесообразность написания автоматических тестов должна определяться на этапе проектирования новой функциональности и оцениваться для каждого из этапов тестирования в отдельности

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

·         Юнит-тесты. Применение автоматизированного тестирования на данном этапе наиболее эффективно с точки зрения соотношения цена/качество:

o        Ошибки найденные на этапе юнит-тестирования, обладают небольшой совокупной стоимостью исправления

o        Количество находимых ошибок на данном этапе максимально

o        Количество итераций перетестирования на данном этапе максимально

o        Автотесты, разработанные для данного этапа тестирования могут с успехом использоваться на других этапах

 

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

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

·         Регрессионное тестирование. На данном этапе должны использоваться автотесты, разработанные ранее для других этапов тестирования. В случае, если необходимо масштабное регрессионное тестирование системы, но при этом регрессионных автотестов нет -  их создание имеет смысл только в случае возможного повторного полного регресса.

·         Нагрузочные тесты. Для данного этапа тестирования, применение автотестов весьма эффективно в силу следующих причин:

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

o        Автоматизация отчёта о нагрузочном тестировании.

·         Интеграционное тестирование. Практика показывает, что тестирование интеграции с внешними системами вручную гораздо более эффективно, нежели применение автоматизированных тестов. Это, в первую очередь, связано тем, что большая часть трудозатрат  (до 50%) в рамках интеграционного тестирования затрачивается на различные настройки и налаживание взаимодействия между смежными системами. Данная работа автоматизации практически не подлежит.

Рисунок 1. Относительная эффективность использования автотестов

 

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

 

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

 

4.4.            Инструменты автоматизированного тестирования

 

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

·         Стоимость лицензии

·         Наличие внутренних скриптовых языков

·         Сложность

·         Производительность

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

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

        Также, очень эффективными являются «самописные» инструменты автоматического тестирования:

·         Тестовые модули/пакеты – небольшие программы, вызывающие тестируемые модули и передающие туда заранее определённые наборы данных и сравнивающие данные на выходе с некоторыми эталонными данными.

·         Генераторы данных/ эмуляторы – модули, эмулирующие работу внешних систем/других частей системы для правильного воссоздания тестовых условий, приближенных к реальным продуктивным.

·         Эталонные модули – модули, реализующие ту же самую функциональность, что и разрабатываемые, но гораздо более простыми средствами. Зачастую,  разработчик использует для реализации сложного алгоритма расчёта приёмы, обеспечивающие максимальную производительность (битовые операции, сложные select'ы и т.д.) или сокращает алгоритм в угоду производительности (убирая из него нелогичные и невозможные на его взгляд ситуации).

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

 

5.      Как определить необходимость и степень покрытия автотестами?

 

Для четкого определения параметров автоматизированного тестирования, необходима определённая методика. Исходя из опыта применения автотестов в проектах, предлагается следующий алгоритм:

 

5.1.            Альфа-тестирование

1.        Время на написание альфа-тестов должно быть запланировано

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

3.        Тестировщики (разработчики автотестов) оценивают возможность дальнейшего применения этих тестов на этапе юнит-тестирования и рациональность их написания.

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

 

5.2.            Как планировать время для создания автоматических альфа-тестов?

Как показывает практика, в автоматизации альфа-тестирования нуждаются не более 30% от разрабатываемых/изменяемых программных модулей. Время на разработку альфа- теста для отдельного программного модуля составляет не более 0.5 от времени его разработки. Соответственно, достаточно заложить в плане на автоматизацию альфа-тестирования не более 15% от общего времени разработки

 

5.3.            Юнит-тестирование

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

1.        Необходимо разбить функциональность системы на небольшие функциональные подмодули. Разбиение должно быть как можно более детальным – чем меньше подмодули, тем оптимальнее будет оценено покрытие автотестами.

2.        Для каждого из подмодулей оценивается время как на ручное тестирование, так и на автоматизированное:

Tdev  -  время, необходимое для разработки автотеста

Tman -  время ручного тестирования

Tref – среднее время, необходимое для изменение автоматического скрипта после изменения функциональности

Tref_manual - среднее время, необходимое для изменение автоматического скрипта после изменения функциональности

nregression = относительное количество тестов, прогоняемых без изменений

Ntotal – общее количество итераций тестирования функционала за предполагаемое время жизни функционала (системы).

 

Tmanual_total = Ntotal *(t_exec_m) + Ntotal * (1-nregression)* Tref_manual

Tautomated_total = Tdev + Ntotal *(1- nregression )* Tref

 

Критерий выгоды автоматизации при использовании бесплатных инструментов тестирования:

 Tmanual_total <= Tautomated_total

 

Для расчёта выгоды автоматизированного тестирования с использованием коммерческих инструментов тестирования, необходимо рассчитать стоимость ручного и автоматизированного тестирования:

∑(Tmanual_total ) – сумма трудозатрат на ручное тестирование частей функционала, которые предполагается тестировать автоматически

∑(Tmanual_total ) – сумма трудозатрат на автоматическое тестирование частей функционала, которые предполагается тестировать автоматически

St – себестоимость тестировщика

Stesting_tool – себестоимость инструмента тестирования

Npart  – удельный вес трудозатрат на тестируемый продукт среди продуктов, которые тестируются соотвествующим коммерческим инструментом тестирования.

Cmanual = ∑(Tmanual_total ) * St

Cautomated = ∑(Tautomated_total ) * St + Stesting_tool*Npart

Критерий выгоды автоматизации при использовании коммерческих инструментов тестирования:

 Сmanual <= Сautomated

 

5.4.            Комплексное, нагрузочное, регрессионное и интеграционное тестирование.

Покрытие автотестами рассчитывается аналогично unit-тестированию, но при этом необходимо учитывать следующие факторы:

·         Возможность использования автотестов, разработанных ранее (на предыдущих этапах тестирования). Может значительно снизить трудозатраты.

·         Возможно, стоит включить автоматизацию отчетности (отчёта о тестировании)

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

 

Автор

Александр Хрущев - менеджер проектов компании Instream

Доклад на конференции CEE-SECR 2009, октябрь 2009