Май 28

Пирамида тестирования на практике. Как работает QA в Jiji

Меня зовут Филипп Кандыба, я Middle Automation QA Engineer в одном из проектов компании Genesis — Jiji. Это маркетплейс, представленный в виде сайта, мобильной, десктопной версий и приложений для iOS и Android.

Тестированием я занимаюсь уже 5 лет, из них автоматизацией последние три года. В мои обязанности входит создание, настройка и поддержка автоматизированного UI-тестирования. Сейчас это 1500 автотестов для веб-версии и тесты для Android-приложения, закрывающие его основной функционал. Также мы разрабатываем проект автоматизированного тестирования для iOS-приложения.

В этой статье расскажу о том, как устроено тестирование в Jiji, какие методологии и подходы мы используем. Материал будет полезен не только QA-инженерам, но и остальным участникам процесса разработки программного обеспечения.

Особенности работы приложений в Африке

Jiji — онлайн-доска объявлений с основным рынком в Африке. Компания работает в нескольких странах и является лидером в своей нише. У рынка Африки есть свои особенности, но мы в Jiji научились приспосабливаться к ним. Например, интернет-соединение в странах, где представлен проект, мягко говоря, не наилучшее, и это стоит учитывать при разработке и тестировании продукта.

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

В то же время мобильные приложения не должны отставать от веба. Jiji для Android скачали уже более 5 миллионов раз, и это показатель только по Нигерии. Но здесь мобильные приложения имеют одну особенность: из-за отсутствия нормального интернет-соединения они могут долгое время не обновляться. Поэтому необходимо поддерживать очень старые версии. Все это также должно быть учтено при тестировании.

Успешно функционирует и мобильное приложение для iOS. Оно тестируется наравне с Android-версией. Хотя айфоны не так популярны среди жителей африканских стран, как андроид-девайсы, показатели по их использованию растут.

Реализация пирамиды тестирования

Понятие пирамиды тестирования широко известно. Ее задача — сгруппировать тесты по разным уровням детализации.

Первый уровень: unit-тесты

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

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

Второй уровень: интеграционные тесты

Суть этого процесса в объединении программных модулей в группы и их последующее тестирование. Проще говоря, это проверка бизнес-логики без использования UI. На проекте интеграционные тесты пишут разработчики и они же их и поддерживают. Однако можно встретить команды, где этот уровень закрывает QA. В этом нет ничего плохого — если человек компетентен и может выполнять подобную работу качественно, то ему стоит это делать.

Третий уровень: тесты пользовательского функционала

Здесь количество тестов должно быть наименьшим. Воссоздавая пользовательские сценарии, мы проверяем приложения на стабильность и работоспособность. На этом уровне тесты самые хрупкие. Да, технологии шагнули вперед, скорость выполнения UI-тестов возросла вместе со стабильностью, однако не ждите постоянно зеленых билдов — flaky-тесты все еще существуют.

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

В Jiji мы стараемся, так сказать, придерживаться традиций. Поэтому используем пирамиду тестирования и пытаемся следовать всем советам, которые она дает.

Как я упоминал выше, в основе тестирования нашего проекта лежат unit-тесты. Их довольно много — порядка 8000. Однако количество никогда не свидетельствует о качестве. Нельзя сказать, что на проекте используется метод разработки через тестирование (TDD), однако вся функциональность — как существующая, так и новая — покрыта тестами. Почти каждый pull-запрос так или иначе содержит в себе изменения файлов с тестами.

Все вышесказанное касается бекэнд-части приложения, однако и фронтенд не отстает. Для него программисты также пишут тесты. Чаще всего — unit-тесты разработанных компонентов. Они быстрые и надежные, поддерживают стабильность и работоспособность приложения.

UI-тестирование

На самом же верху нашей пирамиды, как и положено, находятся UI-тесты. Этот уровень тестирования закрывает QA-команда. Сейчас у нас написаны и постоянно запускаются 1500 UI-тестов — это тесты только для веб-приложения. Все они используют Selenium и написаны на Python.

Язык разработки тестов был выбран в соответствии с основным языком проекта. Такой подход — норма, и я надеюсь, все так делают. Важно, чтобы тесты и их результаты выполнения были понятны разработчикам. Так они тоже смогут вносить правки и знать, что, где и почему «упало». Мы используем репортеры со всей информацией, которую соберем, чтобы после возможного падения теста точно все воспроизвести и выяснить причину.

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

UI-тесты, которые пишем, покрывают несколько версий сайта: десктоп-, мобильную и для планшета. Также для определенных стран у нас есть вариант сайта с отличающийся функциональностью. Он тоже покрыт UI-тестами.

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

Однако не только pytest упрощает нам работу. Как QA-инженер, я пишу небольшие инструменты, помогающие в тестировании. Чаще всего это фикстуры — функции на бекэнде, которые я вызываю через API. Их цель — создать или настроить что-то. Например, пользователя с определенными характеристиками, объявление. Таким образом с помощью фикстур я быстро подготавливаю всю основу для теста, настраиваю окружение и запускаю тест. Это экономит уйму времени.

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

Написанием фикстур могут заниматься все. Однако именно QA-инженер должен создавать и настраивать свой инструментарий. Это позволит познакомиться с проектом изнутри, понять, как все работает, из каких компонентов состоит.

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

Нужно ли на проекте мануальное тестирование

До недавнего времени в Jiji не было мануального тестирования. Так сложилось исторически: все QA было на плечах самих разработчиков и QA Automation-инженера. Спустя время нам таки пришлось нанять мануального тестировщика. Объем выпускаемых фич настолько большой, что без него невозможно даже произвести приемочное тестирование, не говоря уже о более вдумчивой и комплексной проверке нового функционала.

Так как Jiji — не только веб-, но и мобильное приложение, то еще этот отдельный продукт нужно проверять. Наш подход к тестированию Android и iOS-приложений стандартный: мы используем Appium, а все тесты пишутся так же, как и для веба — на Python. На данный момент для обоих приложений созданы автоматизированные тесты для основного функционала.

Разработчики самостоятельно запускают тесты на CI, выбрав перед этим ту ветку, для которой необходимо выполнить тестовый прогон. В будущем есть идея использовать более нативные инструменты для проверки приложений: Expresso и XCUITest.

Дополнительные инструменты для тестирования

Нас интересует не только тестирование UI и модулей. Мы стараемся автоматизировать все, что возможно, для обеспечения безопасности приложений. Чтобы понять, с чего начать, не нужно быть хакером — достаточно воспользоваться открытыми источниками. Например, обратится к OWASP Top 10.

Мы тестируем безопасность путем автоматизированной проверки зависимостей, которые используются на проекте. Есть уйма инструментов, которые уберегут вас от их вреда: safety для Python и обычный npm check для JS.

Мы автоматизировали тестирование XSS-уязвимостей, чтобы всегда быть уверенными, что наши пользователи защищены. Для этого обзавелись простыми тестами, которые присылают нам вредоносный код. Его примеры мы формируем сами, чтобы проанализировать интересные кейсы.

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

Что в результате

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

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