Разрушаем мифы об автоматизированном тестировании!

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

Миф № 1: Зачем нам что-то еще, когда есть автоматизация тестирования?

Заменить автотестами другие виды анализа не получится, потому что для оценки результатов проверки нужен живой, человеческий взгляд. А скрипт не сможет принять окончательное решение за вас.

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

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

Миф № 2: Написал скрипт раз – тестирую и сейчас!

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

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

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

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

Миф № 3: Кто угодно может написать скрипт.

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

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

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

Миф № 4: Скрипт написан и начинается волшебство. Прогоним через него все версии билда!

Эх, было бы здорово, если бы это было так просто! В реальном мире мы анализируем выходные данные скрипта и редактируем его, чтобы идти в ногу с изменениями тестируемой системы. Чем больше у вас скриптов, тем больше вещей, о которых вы должны заботиться.

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

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

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