Миру требуется все больше и больше софта: любой магазин или автосервис хочет сайт или мобильное приложение. Но забагованный софт не хочет никто, нам нравится, когда все работает красиво и корректно. Эффективно искать баги помогает тестирование, и иногда оно проходит автоматически. Вот про этот случай мы и поговорим.
Качество разрабатываемого продукта конечно зависит от всей команды, но давайте выделим тестирование, в нем я разбираюсь. Меня зовут Дмитрий Ремезов, я QA-инженер в Технократии, и в этом тексте я дам вам вводные об автоматическом тестировании: когда оно поможет, а когда от него стоит отказаться. Дам список из плюсов и минусов подхода, и в конце опишу проект, которому точно требуется автоматизация.
Автотесты — инструмент
Мы, тестировщики, хотим переложить бремя регресса на плечи автотестов. Однако автоматизация тестирования — не панацея, а инструмент. А чтобы инструмент работал и приносил прибыль, его сначала нужно правильно подобрать, а затем не забывать обслуживать и иногда менять на новый — лучший.
Следующее предупреждение — существуют спорные кейсы, поэтому к процессу автоматизации стоит подходить обдуманно. Может случиться так, что польза от автоматизированного тестирования не сможет покрыть расходы, затраченные на этот процесс. Давайте подробнее рассмотрим такие кейсы.
Тестирование верстки
Заказчики и пользователи смотрят на приложение глазами, поэтому красивый, качественный интерфейс играет важную роль. Но разные браузеры, их обновления, обновления фронтовых библиотек могут нашу красивую верстку сломать.
Это может затронуть приложение только визуально, а может даже заблокировать функциональность. К примеру, так. Магазин одежды предлагает узнать боль.
Нельзя отрицать плюсы в виде появления нового мема и повышенной посещаемости сайта.
Но бывают более серьезные проблемы. Недавно я поменял телефон. Мой предыдущий девайс имел небольшую диагональ. В конце месяца я зашел в онлайн банкинг обновить категории кешбэка, но нужная мне позиция оказалась под футером и не скроллилась — выбрать эту позицию я не смог. Такая проблема — триггер негодования пользователей, горящей техподдержки, ухода некоторых пользователей и получения убытков.
От этого спасает тестирование. Рассмотрим среднестатистический проект.
имеем:
некоторое количество с разными разрешениями экранов
две популярные ОС
несколько браузеров на вебе.
В ручную проверять верстку долго и не весело. Давайте автоматизировать
В идеальном мире все выглядит так: выбрали фреймворк, затратили время. Автотестер нажимает кнопку, и программа сама пошла тестировать. Профит! Но погодите.
Сейчас редко встречаются приложения со стабильно неизменяемым фронтендом. Чтобы не дать пользователю заскучать и привыкнуть, менеджеры и дизайнеры часто проводят редизайн, освежают интерфейсы. К этому добавим частое обновление UI-китов, выход новых устройств с новыми типами экранов —iPhone и новые MacBook с челкой—, обновление подключённых библиотек, обновления браузеров. Получается удручающая картина.
Помните, я говорил, что тестирование — инструмент? Так вот, автотесты верстки придется постоянно обновлять. А это не всегда просто и быстро. Это надо иметь в виду.
Эмуляция отказа сервера
Это следующий кейс. В чем смысл? Мы имеем микросервисную архитектуру и хотим проверить, как ведет себя приложение, если какой-то из сервисов отвалился. По-хорошему при отказе какого-либо сервиса приложение не должно падать:
В пользовательском интерфейсе должен появиться экран с прогнозируемой ошибкой.
Во фронт не должен лететь стектрейс.
В логи и системы мониторинга должны записаться сообщение об отказе сервера.
Как это сделать в рамках ручного тестирования понятно. Тестировщик получает доступы к серверам. Руками через терминал «опускает» нужный сервис. Затем смотрит, как ведет себя приложение в данной ситуации. Другой вариант развернуть все локально, с помощью сниффера расставить брейкпоинты, и эмулировать отказ сервера.
Что в данной ситуации будет делать автотестер?
Пропишет скрипты с кредами? Тут встает вопрос о безопасности. Разворачивание безопасной тестовой инфраструктуры это процесс, который требует скилов и трудозатрат.
Использовать моки? Грамотное мокирование подразумевает тестирование белого ящика, что не всегда под силу автоматизатору и требует помощи разработчика.
Прогон тестов локально я даже не рассматриваю, так как все мы с тестами целимся в CI. Поднятия такого стенда на отдельной виртуальной машине опять требует допресурсов и, возможно, помощи девопса. Опять же злоупотребление моками и стабами негативно сказывается на качестве автотестов. Об этом написано много статей. Например, вот и вот. Так что не будем заострять на этом внимание.
Нативные окна браузера
Вот где можно открывать ортопедический салон. Все с ними знакомы: они постоянно вылетают и запрашивают разрешения на действия, оповещают о возможных проблемах или предлагают сохранить креды.
Сколько обсуждений в интернете, сколько собственных костылей, сколько стараний разработчиков фреймворков. И, вроде, все ясно и понятно, но каждый раз натыкаешься, и не всегда можешь справиться.
Приведу пример из собственного опыта. Недавно перешел на новый проект. На стенде есть банальное флоу: кнопка связи с техподдержкой. После нажатия открывается новая вкладка с номером телефона и заглушкой, которые зависят от региона, введенного пользователем при регистрации.
Нужно было проверить, что выводится правильный номер телефона и заглушка. Но есть нюанс, как в анекдоте, ага. Когда открывается новая вкладка, появляется нативное окно. Оно предлагает открыть дефолтное ПО для совершение звонка. И вот это нативное окно блокирует дальнейшие действия на странице, и я не могу на него ткнуть, могу только вкладку закрыть. Вошел в азарт, потратил 3 дня. Но так и не решил. В итоге проверяю линку, привязанную к кнопке, а проверку заглушки оставил для ручного тестирования.
Как вы думаете в чем суть данного примера? Нужно рассчитывать свое время и силы. Потратил кучу времени, а толку так и не добился. А ведь мог остановиться раньше.
Пока вы возитесь с задачей, которую не можете решить, вы бы могли написать несколько других тестов, которые бы уже начали приносить пользу проекту .
Я упоминал, что не все однозначно. У автоматизации есть плюсы и минусы. Так они выглядят, на мой взгляд.
Плюсы:
Исключение человеческого фактора: автотесты не устают, не страдают рассеянным вниманием и не могут пропустить баг после ссоры с женой. Им вполне нормально работать 24/7.
Скорость. В разы превосходит скорость ручного тестирования.
Многопоточность. Человек не может, а автотесты могут в параллель проверять разные окружения, применять разные настройки или поднимать неограниченное количество пользователей.
Минусы:
Автотесты требуют актуализации. Выход новых фич может влиять на функциональность приложения, что делает тесты неактуальными. Время на обновление автотестов прямопропорционально количеству тестов.
Автоматизация тестирования не гарантирует 100% поиск дефектов. Программа работает в узком заданном флоу. Что написано в коде, то и пройдет проверку. В то время, как человек может обратить внимание на какие-то моменты, которые идут не так, но не заложены в рамках тест-кейса.
Все таки существуют кейсы, которые заавтоматить нельзя. Пока. Исследования в области искусственного интеллекта идут полным ходом, так что ждем.
Спорные моменты:
Автоматизация тестирования требует квалифицированного специалиста и значительных трудозатрат на старте. Однако если все проходит гладко и по плану, то использование автотестов практически бесплатное. Правда, при неправильном подходе или планировании затраты на автоматизацию могут не окупиться.
Чтобы автоматизация на проекте не стала узким местом, зависящим от одного сотрудника, который ее написал, нужно разрабатывать общедоступные стандарты в отделе тестирования, стиль написания кода и пользоваться одинаковыми инструментами автоматизации. Такая система гарантирует сменяемость специалистов, ведь отпуск, больничные и увольнения никто не отменял. Однако внедрение каких-то новых инструментов становится трудно реализуемым, так как требует переработки стандартов и обучения персонала.
После всего этого составим картину проекта, которому требуется автоматизация тестирования:
Регресс требует большого количества человеческих и временных затрат. Если проект дорос до момента, что ему для проведения регресса требуется отдельный отдел тестирования, или регресс занимает больше 50% спринта, то это звоночек для внедрения автоматизации.
На проекте нет возможности отказаться от поддержки старых версий ПО. Возможность автотестов работать многопоточном режиме решит эту проблему.
Видно влияние человеческого фактора. Из-за усталости, «замыленности глаза» или нехватки времени на прод стали просачиваться баги.
Пора подводить итог. Есть кейсы, которые пока нельзя автоматизировать, кейсы, которые нужно автоматизировать, и спорные кейсы. То есть сразу не очевидна, будет ли выгода от них. Как вообще определиться автоматизировать данные кейсы или нет?
Этим должен заниматься квалифицированный тестер, который представляет, как это сделать, сколько времени понадобится. Приблизительный подсчет трудозатрат перед реализацией какой-либо функциональности — своего рода искусство, которому тоже необходимо учиться.
Нужно понимать, на какой стадии находится покрываемая фича. Просчитать риски, связанные с гибкой методологией разработки.
Регулярно просчитывать коэффициент возврата инвестиций. Есть разные методики расчета, но мне нравится формула доход делим на расход. И вот есть коэффициент меньше или равен единице, то толку от этой автоматизации никакого.
Не забывайте про пирамиду автоматизации тестирования. Не стоит с шашкой наголо рваться покрывать UI, если нет автоматизации тестирования API.
Таким образом, автоматизировать или не автоматизировать, решать вам. Примеры, которые я привел, можно покрыть автотестами. Я хочу сказать о том, что к автоматизации тестирования нужно подходить обдуманно. Нужно стараться, чтобы работа приносила максимальную пользу, а не упарываться в какие-то трудно выполнимые задачи.
Таким образом автоматизируйте осмысленно! Да прибудет с вами сила!
Также подписывайтесь на наш телеграм-канал «Голос Технократии». Каждое утро мы публикуем новостной дайджест из мира ИТ, а по вечерам делимся интересными и полезными мастридами.
