Инструкция по использования тестового сценария

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

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

Анализ полученных результатов

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

Для анализа полученных результатов использовались следующие метрики.

Производительность выполнения тестовых сценариев ручным способом (кол-во/час)

где ТР — производительность ручного тестирования,.

NT — количество выполненных тестовых сценариев, Т_m — время, затраченное на выполнение всех ручных тестовых сценариев.

Производительность выполнения тестовых сценариев автоматическим способом (кол-во/час)

где АТР — производительность автоматического тестирования,.

NАT — количество выполненных автоматических тестовых сценариев, Т_a — время, затраченное на выполнение всех автоматических тестовых сценариев.

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

Выигрыш перехода от ручного вида тестирования к автоматическому (ч)

где.

n — количество выполненных автоматических тестов,.

t_m — время, затрачиваемое на выполнение одного теста ручным способом,.

t_a — время, затрачиваемое на выполнение одного теста автоматическим способом,.

t_ap — время, затрачиваемое на подготовку к автоматическому тестированию.

Количественный анализ. Расчет разницы между ручным и автоматическим тестированием по времени

Анализ работы применяемого инструмента для тестирования Cucumber показал, что на выполнение теста на один элемент проверки соответствия тратится от 0,5 до 1,5 минут в зависимости от конфигурации. Автоматическое тестирование всех имеющихся элементов проверки соответствия в версии продукта 2.1 занимает 7,5 часов, то есть около одного рабочего дня одного члена команды.

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

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

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

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

Поскольку уже известно количество элементов проверки соответствия, для которых будет проведено регрессионное тестирование для ПО версии 2.3, можно рассчитать затраты временных ресурсов для данного вида деятельности команды. В итоге, количество дней, высвобожденных после внедрения автоматического тестирования для 2.3 релиза, составляет 65 рабочих дней при условии выполнения регрессионного тестирования 1 человеком дважды за жизненный цикл этой версии программного продукта. Для версии продукта 2. k это значение составляет .

Текущая и спрогнозированная тенденция прироста времени после внедрения автоматического тестирования отображена на графике на Рис. 2.

Рис. 2 Тенденция прироста времени (в днях) после внедрения автоматизированного тестирования

Расчет разницы между ручным и автоматическим тестированием по производительности

Если говорить о производительности, то регрессионное тестирование 500 элементов проверки соответствия версии 2.2 ПО занимало бы 31 день, производительность ручного тестирования составила 16 тестов в день. Аналогичная метрика для производительности автоматизированного регрессионного тестирования элементов проверки соответствия дает результат в 111 тестов в день. Из этих данных полагаем, что при переходе от ручного регрессионного тестирования элементов проверки соответствия к автоматическому производительность команды относительно данного вида деятельность увеличится почти в 7 раз. Таким образом, автоматизация тестирования значительно повышает уровень производительности команды и благоприятно сказывается на временных и человеческих затратах при проведении регрессионного тестирования элементов проверки соответствия.

Качественный анализ. Основой качественного анализа является анализ преимуществ и недостатков автоматического тестирования, применимых к текущему проекту.

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

Во-вторых, создав однажды такой сценарий, сотруднику не придется каждый раз тратить время на его обслуживание: от версии к версии методы, отвечающие за проверку соответствия, остаются неизменными (проанализирована применимость полученных автоматических тестов на 3 предыдущих релизах). В этом случае определенно прослеживается такое преимущество автоматического тестирования как снижение трудоемкости, поскольку всё, что необходимо сделать тестировщику — это поместить требуемые файлы, отражающие конфигурацию, в соответствующие им директории.

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

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

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

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

Одним из недостатков автоматического тестирования является риск пропуска определенного вида дефектов. Однако, как показывает анализ Таблицы 1 обнаруженных дефектов, инструмент для автоматического тестирования отслеживает все важные недостатки, что также является весомым преимуществом в пользу автоматического тестирования. Результаты представлены в таблице:

Таб. 1 Количество обнаруженных дефектов.

По классификации дефектов тестирования, а именно по Градации Серьезности дефекта (Severity), существуют major и minor дефекты, «значительный» и «незначительный» соответственно. Существуют и другие уровни значимости дефектов: blocker — «блокирующие», critical — «критичные» и trivial — «тривиальные». В процессе ручного тестирования дефекты таких уровней не были обнаружены, поэтому не участвуют в анализе. Они характеризуют влияние дефекта на работоспособность приложения в определенной мере. Таким образом, при обнаружении дефекта ранга major тест получает статус failed. Текущий статус говорит о том, что объект тестирования не отвечает заявленным требованиям. Поскольку дефект типа minor незначительно влияет на программное обеспечение, тест получает статус passed.

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

Другим недостатком автоматического тестирования является то, что инструмент для тестирования не может отследить ошибки, связанные с внешним оформлением программного обеспечения (GUI), сопутствующие ошибки функционала ядра (такие как неточности в позиционировании окон, ошибки форм и т. п.). Также упускается проверка дружественности интерфейса (usability): автоматизированный тест не может оценить дружелюбность, цветовую гамму, красоту и стиль интерфейса разрабатываемого продукта, это, несомненно, является недостатком автоматизации; с другой стороны, при ручном тестировании мнение тестировщика в данном вопросе может быть субъективным и не отражать реального состояния дел.

Более того такие важные нюансы учитываются во время других видов ручного тестирования, поэтому это так же не является существенным недостатком, влияющим на принятие решения о недопустимости автоматизации. Хочется отметить, что 100-процентная автоматизация не является совершенной альтернативой ручному тестированию. Дефекты, которые были найдены при ручном тестировании и являются косвенными по отношению к элементам проверки соответствия, также могут оказать влияние на статус соответствующего теста. Именно такую картину отражает таблица: при ручном тестировании было обнаружено 10 недочетов типа major, 2 из которых относятся к функциональной части программного обеспечения и не могут быть замечены инструментом Cucumber. Так как их количество невелико, то, принимая во внимание очевидные выгоды автоматизированного тестирования, здесь также было принято решение о допустимости данного процента ошибок при автоматизированном регрессионном тестировании элементов проверки соответствия.

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

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

Как уже было отмечено, автоматическое тестирование имеет свои преимущества и недостатки и не служит панацеей в погоне за выигрышем во времени.