Как мы автоматизируем тестирование для суперапа

Прошлой весной мы ввели автотестирование на одном из наших проектов и хотим рассказать о результатах эксперимента. Проект представляет собой набор из трех iOS и трех Android приложений для подготовки к экзаменам по вождению — для автомобилистов, мотоциклистов и водителей автобуса. Каждый месяц ими пользуется более 400 тысяч человек. Мы работаем над проектом уже 7 лет, но тесты всегда были только ручные.

Глобальная перемена произошла в прошлом году: приложения объединили в одно суперприложение. Теперь пользователь может выбрать необходимое транспортное средство (car, moto, bus) на онбординге или переключаться между ними внутри приложения, чтобы перейти к соответствующему набору экзаменационных вопросов.

Для тестирования это значит, что любое изменение затрагивает сразу 3 (точнее, 3х2) приложения, которые находятся внутри одного. То есть нужно одновременно задействовать большее количество QA-специалистов.

Мы предложили заказчику внедрить автотесты, чтобы закрыть несколько задач:

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

Рассмотрим на примере экрана приложения. Здесь есть вопрос, варианты ответов и кнопки: возврат на главный экран, меню, переключение между вопросами, вызов подсказки («Hint»), добавление в закладки.

Автотестами можно проверить:

1. Правильность тапов на кнопки

Мы используем функциональные UI-тесты, которые дублируют действия пользователя. Например, чтобы протестировать кнопку «Hint», автотесту хватило 8 секунд.

2. Корректность изменения данных

На экране есть счетчик вопросов — сейчас открыт 9 вопрос из 40 имеющихся. Автотест проверяет правильность этого значения на каждом шаге.

3. Отображение текста

При любом ответе на вопрос (даже неправильном) на экране появляется пояснение к верному варианту. Тест проверяет, чтобы это случалось всегда.

Автотестирование хорошо работает на функционале, но его сложно применить в части UI/UX. Картинку, цвета, расположение элементов, взаимодействие со стором и почтой, частичную проверку базы данных лучше оставить в ручном режиме.

У заказчика уже был некий каркас фреймворка на Python, поэтому мы продолжили работать на нем. Среда тестирования — PyTest. Для работы с симуляторами мы используем Xcode и Android Studio, для автоматизации — Appium.

Удаленный старт автотестов осуществляем через CI/CD и GitLab — iOS и Android запускаются отдельно по одному клику. Отчеты создаются в фреймворке Allure.

После прохождения теста кейс автоматически заполняется в TestIt. Синхронизация между ним и PyCharm происходит по ID теста.

Для удобства взаимодействия с элементами мы используем factory метод. Для хранения локаторов элементов создали папку page_objects, для выполнения действий над элементами экрана — папку actions. В каждой из них находятся три подпапки — base, ios, android. В base происходит инициализация метода, а в ios и android реализованы соответствующие шаги для каждой из платформ. Особое внимание уделили корректности нейминга локаторов элементов — это важно для UI-автотестов.

Несмотря на идентичность, каждое из трех исходных приложений (car, moto, bus) имеет свои данные. Ответы на вопросы, названия тестов, список штатов и остальная информация хранятся в базах данных (SQL Lite). Поэтому в папке data_base находятся три базы данных — для разных транспортных средств.

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

Также есть общий conftest файл. В нем хранятся сгруппированные actions, которые периодически повторяются — для уменьшения дублирования кода в тесте. Например, шаг «пройти онбординг» содержит в себе несколько шагов, но в тесте мы его увидим как единый метод.

Рассмотрим на примере: реализуем проверку отмены рестарта теста.

1. В Appium инспекторе ищем нужные элементы экрана для ios и для android
2. Сохраняем их в соответствующих папках и инициализируем в base
3. В steps реализуем порядок действий, которые состоят из нескольких actions — pass_unlocked_test_and_stay_on_review_screen
4. В conftest сохраняем необходимые данные (названия штата, квиза и блока) для каждой страны в подпункте — restart_quiz
5. Создаем тест:

- Прописываем маркер для Allure

- Название теста с импортом необходимых параметров

- Комментарий (в данном случае — название и ID для TestIt)

- С помощью условия if status_variables.app_name выбираем нужное приложение

- Общие шаги, реализованные в отдельных методах

Чтобы запустить тест для определенной платформы, выбираем IOS или ANDROID в настройках capabilities.

Для запуска тестов конкретного приложения из трех прописываем путь к нужной базе и указываем его в классе DBHandler

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

Удаленно автотесты запускаются через CI — отдельно для iOS и Android. Сам отчет генерируется в Allure и является наглядным.

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

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

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

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

Для масштабных и длительных проектов нужна совокупность обоих методов. Мы также добавляем к ним UNIT-тесты, которые проверяют корректность отдельных модулей исходного кода программы.

Автор: Юлия Бойко

Редактор: Елена Майорова