"Об автоматизации тестирования"

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

Автоматизированное тестирование лучше ручного

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

100% автоматизированное тестирование

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

Быстрый ROI (окупаемость инвестиций)

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

Высокий уровень обнаружения дефектов через автоматизированное тестирование

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

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

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