От тест-кейса к коду: как и зачем автоматизировать UI-тестирование

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

Но зачем вообще автоматизировать тестирование? Так мы получаем сразу несколько преимуществ:

• Ускоряем прохождение регрессионного, smoke- и интеграционного тестирования. На ручное тестирование интерфейса уходит много времени и сил. Автоматизация позволяет освободить ручных тестировщиков от рутинной работы — например, проверки десятка похожих друг на друга разделов сайта или приложения.
• Масштабируем проверки. Один и тот же набор тестов можно многократно запускать на разных сборках и версиях ОС, чтобы выявить баги или убедиться, что функциональность работает.
• Быстро находим проблемы и сразу на них реагируем. У нас есть возможность запускать тесты регулярно (например, каждое утро) и получать подробный отчет о результатах.
• Упрощаем работу со сценариями, которые требуют предзагрузки больших объемов данных. Например, с инструментами автоматизации мы можем быстро создать тысячу заметок или загрузить на планшет большое количество файлов разного размера и формата. Воспроизвести всё это вручную было бы гораздо сложнее.

Но всё не так радужно, как может показаться на первый взгляд. Минусы у автоматизации тоже есть. Перечислю основные:

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

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

Как и в любой другой работе, всё начинается с ТЗ от заказчика. Я получаю тест-кейс, описанный в нашей тест-менеджмент системе TestY. Выглядит это примерно так:

Дальше мы с командой оцениваем тест-кейсы на сложность по системе T-Shirt Sizing, выделяем неточности и проблемы. Этот процесс называется грумингом — по сути, это «причесывание» задач, анализ их деталей, уточнение спорных моментов. Груминг часто применяется в SCRUM-командах: с его помощью можно оценить объем и рассчитать силы до начала планирования спринта.

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

Когда возникают такие неоднозначные ситуации, необходимо уточнить ТЗ у заказчика: посмотреть автора тест-кейса и написать ему лично. Приведу в пример частые вопросы, которые возникают у меня:

• В тест-кейсе важно проверить, что определенная функциональность доступна пользователю, или еще и протестировать ее работу? Например, мне достаточно проверить, что при попытке поделиться файлом в окне появляется функция Bluetooth, или нужно физически отправить файл по Bluetooth на другой девайс? Второе, кстати, в случае автотестов может быть весьма проблематично.
• Что значит фраза «Всё отрабатывает как надо» или «Поведение соответствует ожидаемому»? Как понять, что мы подразумеваем под «как надо» и «ожидаемым поведением»?
• Почему название кнопки вдруг поменялось? Это ожидаемое поведение или баг?

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

При изучении ТЗ иногда приходится рушить мечты заказчика. Помните же, что ТЗ в нашем случае — это тест-кейс, а заказчик — это ручной тестировщик? Правда в том, что не все тест-кейсы можно и нужно автоматизировать. И когда автоматизатор оказывается в такой ситуации, перед ним встает задача: найти компромисс с заказчиком и предложить решение (но с некоторыми оговорками) или отказать сразу на этапе выдачи ТЗ и не давать ложных надежд.

Разберем оба случая на примерах:

Первый случай — идем на компромисс. В недавнем тесте мне нужно было проверить такой процесс: если навести курсор на поле ввода, он должен начать мигать (cursor is blinking). После некоторого исследования и общения с разработчиками, выяснилось, что Android не предоставляет API для проверки такой функциональности, поэтому мы приняли решение пойти на компромисс. Вместо мигающего курсора проверили, что поле ввода при нажатии переходит в фокус и в нем можно писать.

У планшета KVADRA_T, который я тестирую, своя операционная система kvadraOS на основе AOSP. Поэтому команды и инструменты, которые я приведу, в большинстве своем предназначены для Android-девайсов. Сразу отмечу, что при написании тестов я работаю только с одним девайсом. В это время физически он находится у меня в руках или лежит на столе.

С помощью провода TYPE-c — TYPE-c (или TYPE-a — TYPE-c) подключаем планшет к ноутбуку: тут важно сказать, что у девайса должен быть включен режим отладки по USB, иначе ваш ноутбук просто не увидит устройство и не сможет выполнять команды. Для проверки того, что всё прошло успешно, можно ввести в терминале:

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

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

Предположим, что тест написан и успешно запускается на локальном планшете. Теперь возникает вопрос, а как этот тест сможет запустить кто-то извне — например, в рамках регрессионного или smoke-тестирования? Для этого у нас есть удаленный стенд с планшетами, подключенными к KVADRA D20. Так выглядит наш стенд в офисе:

Чтобы проверить работоспособность написанных тестов, мы пользуемся пайплайном в Jenkins. Шаги такие:

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

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

Как только тест успешно прошел все этапы проверки, начинается код-ревью — а вместе с ним и возможное исправление неточностей.

В нашем дивизионе тестирование автоматизируют преимущественно на Python. Так что для разработки автотестов мы выбрали именно этот язык — это самое быстрое и практичное решение.

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

Начнем с инструмента Appium. Если совсем просто, это сервер, который вы запускаете локально, например, через командную строку. Он слушает порт (например, 4723): автотест через Appium Client шлет на него HTTP-запросы с командами WebDriver, а сервер преобразует их в нативные жесты на устройстве. При этом работает Appium с разными языками, операционными системами и приложениями.

Что представляет из себя Appium Client? Если вы когда-либо автоматизировали тестирование веб-интерфейса, вам точно известен Selenium. Этот инструмент стал популярным благодаря протоколу WebDriver — стандарту взаимодействия с пользовательским интерфейсом через HTTP-команды: нажать на кнопку, найти элемент, закрывать текущую вкладку и так далее. Неравнодушные разработчики подумали и решили перенести идею WebDriver-автоматизации с браузеров на мобильные устройства. Если прописать в коде команды из стандартного API, клиент сформирует и отправит HTTP-запросы на Appium Server. Тот обработает их и воспроизведет результат на конечном устройстве. При этом команды не нужно изменять под конкретную ОС, будь у вас Android, iOS или даже веб-браузер. Если хотите найти и нажать на кнопку, достаточно прописать:

Получается универсальный инструмент, который позволяет через код взаимодействовать с устройством и автоматизировать UI-тесты.

Внимательный читатель задаст вопрос, а как Appium понимает, с какой платформой приложения он взаимодействует? И тут мы плавно переходим к Platform Driver, который необходим Appium-серверу для отображения действий уже на самом устройстве.

Для девайсов на базе Android (как раз наш случай) — это UiAutomator2 Driver. Для iOS, например, это будет XCUITest. Appium устанавливает и запускает вспомогательный automation-сервер на устройстве, чтобы после установки соединения с Appium-сервером UiAutomator2 Server вызвал нативные библиотеки Android и смог выполнить поставленные в коде задачи.

В виде схемы вся эта мудреная последовательность действий выглядит так:

Физическое устройство — ограниченный ресурс: в отличие от виртуального окружения его нельзя пересоздать за несколько секунд. Один и тот же планшет не получится одновременно использовать в нескольких CI-запусках (пайплайнах), поэтому приходится отдельно управлять доступом к нему и тщательно следить за его состоянием.

Еще одна проблема связана с тем, что прошивка или перезагрузка планшета не всегда предсказуемы и могут завершиться с ошибкой. В таких ситуациях девайс приходится временно выводить из общего пула и восстанавливать вручную. Если этого не сделать, могут сломаться все последующие пайплайны. Поэтому необходимо внедрять дополнительные механизмы: health-check устройства, сценарии для восстановления «сломанных» девайсов и проверки, что они действительно вернулись в рабочее состояние после обновления или перезагрузки.

До того, как я попала в отдел тестирования YADRO, я ни разу не работала с физическим девайсом. У меня не было четкого понимания, как устроены автотесты изнутри. Оказалось, писать их — это интересная и комплексная работа, которая требует не только знаний языка программирования, но и погружения в особенности написания автотестов на физический девайс, поскольку работа с ним накладывает определенные ограничения по сравнению с автоматизацией на эмуляторах или веб-автоматизации. При грамотно выстроенном процессе автоматизации можно существенно сократить трудозатраты на регрессионное тестирование, позволив тем самым ускорить цикл разработки продукта и повысить его качество.

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