Автоматизация функционального тестирования: что это такое и как это может быть полезно

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

1. Сбор требований (справедливо для «внешнего тестирования»)
2. Создание тестовой модели (что и как тестируем)
3. Проведение тестирования
4. Отчет о тестировании (дефекты, проблемы и т.п)

Каждая стадия включает в себя исключительно ручной труд. И для каждой новой версии приложения необходимо проводить регрессионное тестирование — повторять следующие стадии:

1. Дополнение тестовой модели
2. Проведение тестирования
3. Отчет

Причем стадия «Проведение тестирования» включает в себя тестирования всего объема функциональности – и старого, и нового. Таким образом получается, что с ростом функциональности растет и объем ручного тестирования, причем тестирование «старого» функционала совершенно справедливо вызывает у тестировщика отторжение – «я уже 10 раз это смотрел». Следовательно, падает и качество тестирования (снижение внимания), и скорость проведения полного тестирования системы. Регрессионное тестирование ведет к регрессу тестировщиков. Автоматизация призвана и ускорить процесс тестирования, и избежать деградации тестировщиков.


Рассмотрим тестовый сценарий, состоящий из ввода данных в форму из 10 полей и контроля результата – таблицы из 20+ строк, в которой нас интересует одна строка, содержащая только что введенные нами данные. Посчитаем и сравним временные затраты на запуск автотеста и ручного теста.

Ручное тестирование:

1. Ввод данных, ~10*5 секунд = 50 секунд
2. Отображение таблицы – 2 секунды
3. Поиск нужной строки – 5-15 секунд
4. Проверка соответствия введенных данных и строки – 10*3 = 30 секунд

Итого на один запуск – 87-102 секунды
Автотест:

1. Ввод данных — ~10*0.1 = 1 секунда
2. Отображение таблицы – 2 секунды
3. Поиск нужной строки – 0.5 секунды
4. Проверка соответствия введенных данных – 0.5 секунды

Итого на один запуск – 4 секунды.

Таким образом временная экономия на запусках составляет 83 секунды или 25 раз (автотесты работают практически со скоростью ответа сервера). И это простейший тест-кейс из одного шага. А если у нас 100 тесткейсов по 10-15 шагов в каждом? Тогда человекомесяцы превращаются в один календарный день. Впечатляет? И дело здесь не только в экономии средств, но и того, чего никогда не хватает – времени.

Но есть и «подводные камни». Я не случайно заостряю внимание на экономии на запусках – сам автотест необходимо еще и написать. Обычно именно это является основной причиной нежелания внедрения автоматизации тестирования. Доводы приводятся следующие: «сейчас у меня 10 тестировщиков низкой квалификации по n-денег, а автоматизация потребует двоих, но за n*4. Экономии практически никакой, а проблем с внедрением много.» Но если продукт растет, то через какое-то время нужно будет уже не 10, а 15-20-30 тестировщиков, а количество автоматизаторов, если и вырастет, то незначительно. Автотесты же не нужно переписывать все, нужно только создавать новые и поддерживать в актуальном состоянии существующие в случае изменения покрываемого ими функционала. И экономия уже не будет такой эфемерной, даже исключая расходы на управление всеми этими 15-20-30 ручными тестировщиками.

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

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

Автоматизация тестирования – не страшный и дорогой нечто, доступое только избранным, а реальное средство для уменьшения энтропии :)

P.S. В качестве средств автоматизации могу порекомендовать:

• Для Web-приложений – Selenium
• Для Win-приложений – White Framework
• Для больших бюджетов – HP Quick Test Pro