Всем привет! Я Светлана Кирдяйкина, старший инженер по тестированию в Авито. Работаю в подразделении, отвечающем за пользовательский опыт. Мой путь в тестировании начался 13 лет назад и за это время я точно поняла, что проверять всё вручную — довольно утомительно.

Для ручного тестирования нужно много ресурсов. К тому же, мало кому нравится регулярно повторять одинаковые действия очень много раз. Если вы задумываетесь про оптимизацию своего времени и улучшении тестирования — эта статья точно будет вам интересна. Здесь я постаралась простым языком описать факторы, на которые стоит обратить внимание перед тем, как начинать автоматизацию. Так этот процесс станет понятнее даже далеким от тестирования читателям. 

Что внутри этой статьи:

Что такое автоматизация и чем автоматизированное тестирование отличается от ручного?

Зачем вообще нужна автоматизация тестирования?

Восемь признаков того, что пора задуматься о переходе на автотесты

На какие подводные камни можно наступить на пути к автоматизации?

Частые ошибки при переходе к автоматизации

Плюсы и минусы автоматизации

Нужно ли автоматизировать все?

Нужна ли автоматизация?

Что такое автоматизация и чем автоматизированное тестирование отличается от ручного?

Попробую дать простое определение. Автоматизация — это метод тестирования, в котором описываются и воспроизводятся нужное количество раз сценарии, аналогичные ручным проверкам. То есть в автоматизированном тесте мы описываем все действия и проверки, аналогичные тем, что производит человек. В процессе выполнения автотеста также могут генерироваться разные необходимые данные (например, при проверке формы регистрации пользователя), сравниваться ожидаемые и фактические результаты, формироваться отчеты. Основные отличия от ручного тестирования – в том, что автотесты не устают, не пропускают часть проверок, прогоняются сколько угодно раз, экономят время на тестирование. Но всё ли так радужно с автотестами? Давайте разбираться.

Зачем вообще нужна автоматизация тестирования?

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

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

Восемь признаков того, что пора задуматься о переходе на автотесты

Допустим, вы понимаете, что в вашей компании всё тестирование проводится вручную, а идея автоматизировать регресс звучит очень заманчиво. Перед этим важно понять – стоит ли вам вообще автоматизировать и что нужно учесть до начала, чтобы не оказаться «у разбитого корыта»? Вот, на что стоит обратить внимание:

• Срок жизни вашего проекта или конкретной функциональности (фичи). Например, вы работаете над экспериментальной фичей, которая равновероятно будет развиваться или будет удалена. Стоит ли автоматизировать тесты для неё? Скорее нет, чем да. 

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

• Размер проекта играет немаловажную роль в принятии решения. Если в вашем проекте много разного функционала, то менять одну часть и каждый раз вручную убеждаться, что вы не поломали другую, — очень трудозатратно.

• Активность проекта. Если ваш проект не изменяется и его не собираются улучшать или заменять, то автоматизировать для него тесты бесполезно.

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

• Возможность автоматизации вашего функционала. Например, вы работаете над функциональностью совершения звонков. Сможете ли вы автоматизировать все ваши кейсы? Скорее всего, нет.

• Готовность других процессов на проекте. Например, есть ли на проекте процесс непрерывной интеграции (CI)? Максимальную пользу автотесты принесут именно в паре с CI — условия запуска будут равны для всех автотестов и команда будет получать обратную связь (отчеты) от автотестов достаточно быстро.

• Готовность команды и ваших QA заниматься автоматизацией. Команде важно понимать, зачем это нужно и что это даст. Также важно понимать, сможет ли нынешняя команда заниматься автоматизацией. Если всё тестирование проходило вручную, то возможно, что вашим инженерам не хватит навыков и опыта для построения автоматизации на проекте.

Пример такого кейса в Авито 

Если вам будет интересно послушать подробнее, то Алексей Шпирко в 2019 году рассказывал эту увлекательную историю в своем докладе на AppsConf, жмите вот сюда.

В далёком уже 2018 году релизный цикл мобильных приложений в Авито занимал целый месяц. Команд разработки на тот момент уже было много, все работали над своими фичами, а потом дружно треть месяца проверяли сборку, которая могла даже не дойти до наших пользователей. 

Регресс в 10 дней – это много или мало? Достаточно, чтобы разработчики успели «напилить» ещё функционала, который может потенциально сломать предыдущую сборку. Лучшие умы мобильной разработки Авито собрались и начали решать эту проблему путем автоматизации. Что мы имеем сейчас: релизный цикл — 1 неделя, регресс — 1 день, более 6 000 автотестов на каждую платформу (iOS, Android).

На какие подводные камни можно наступить на пути к автоматизации?

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

• Инженерам, которые будут заниматься автоматизацией, лучше сосредоточиться именно на автоматизации. Не стоит давать такие задачи в нагрузку к текущим по проекту. Лучше запланировать дополнительные ресурсы на разработку и время на внедрение и поддержку автотестов. 

• Отсутствие CI. При автоматизированном тестировании без CI тестировщик сам решает, на каком окружении и когда запускает автотест, из-за чего результаты тестов могут быть недостоверны. Например, локальное окружение тестировщика может быть настроено на особый лад, а у пользователей таких настроек нет — соответственно, результат прохождения одинаковых шагов у тестировщика и пользователя будет разниться. 

• Наличие необходимой инфраструктуры для запуска автотестов. Например, для веб-тестов нужны тестовые машины с разными браузерами или сторонние сервисы; для тестов мобильных приложений нужна ферма девайсов – реальных или виртуальных (эмуляторы/симуляторы).

Частые ошибки при переходе к автоматизации

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

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

Представим ситуацию: вы выбрали инструмент, написали тесты, запустили – а отчетов нет. Оказалось, что система создания отчетов не подключена. Подключили отчеты — пришлось переделывать фреймворк, который изначально не предполагал наличие системы отчетов, и так далее.

• Отсутствие поддержки автотестов после написания. Менеджеры проектов и тестировщики порой полагают, что когда автотесты написаны и проверены, про них можно забыть. Однако при развитии продукта придется развивать и тесты. Именно поэтому необходимо закладывать время на поддержку уже существующей автоматизации и разбор результатов. За всеми тестами стоит следить и определять, почему именно автотесты «падают». 

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

Плюсы и минусы автоматизации

Плюсы:

• повторяемость результата;

• экономия времени и ресурсов на рутинных действиях; 

• более четкие и понятные проверки результатов работы;

• ускорение регресса. 

Минусы: 

• постоянная поддержка автотестов;

• «падение» автотестов не из-за ошибок функционала, а из-за нестабильности окружения; 

• трудозатраты на создание автотестов, когда регресс еще не покрыт, могут быть больше, чем затраты на ручное тестирование.  

Нужно ли автоматизировать все?

Есть некоторые ограничения автоматизации. Разберу их подробно:

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

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

Нельзя автоматизировать и look‑and‑feel — оставьте это дизайнерам. К тому же, иногда используется не только интерфейсная проверка, а UX-тестирование уже напрямую зависит от человека. 

А также всё, что связано с интерфейсами (например, анимации), чаще проверяется вручную. 

Нужна ли автоматизация?

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

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

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

Хотите больше статей о тестировании в Авито? Их можно найти вот здесь.