Всем привет. Отойду немного от чистой практики и немного посвящу времени самой теории автоматизированного тестирования. Все этого время мы рассматривали внедрение автоматизированного тестирования, но ни разу не оговаривали моменты, когда оно нецелесообразно. Что же, начнем…

Автоматизированный тест (автотест) – это скрипт, который имитирует взаимодействие юзера с приложением, задачей которого является нахождение ошибок (багов) в работе приложения.

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

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

Выборка тестов для автоматизации

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

Например, следующие случаи автоматизировать невозможно:

– проверка содержимого видео или картинки;

– проверка содержимого в напечатанном принтером файле;

– инсталяция операционной системы.

Стоимость

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

Также много средств уйдет на внедрение непрерывной интеграции (Continuous Integration), а также поддержку автотестов.

Поддержка

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

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

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

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

Например, в ранних версиях приложения было “Файл -> Опции”. Вышла новая версия приложения и в ней пункт разделился на два – “Файл -> Параметры” и “Файл -> Настройки”. Автоматизированный тест будет и далее искать раздел “Опции”, но не найдет “Настройки”.

Или же может изменится время загрузки страницы. Допустим, ранее она загружалась за 3 секунды, сейчас это занимает около 30. Возможно, в данный момент слабая скорость соединения или тормозит база. Автотест этого понимать не может, он будет ждать 15-20 секунд и выдаст ошибку “Ошибка: Страница не загрузилась”. В этом случае также придется дорабатывать автотест.

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

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

Немного плюсов автотестинга:

– Автоматизированные тесты работают намного быстрее, чем человек;

– Автоматизированные тесты проходят с большой точностью;

– Автотестинг повышает качество продукта;

– Автотесты могут проходиться круглосуточно и без участия тестировщика;

– Автотестинг можно использовать почти во всех процессах тестирования.