Тестирование мобильных приложений *

Привет, Хабр! Вы когда-нибудь тратили слишком много драгоценного времени на поиск нужного testTag в иерархии Compose Screen? А потом ещё полдня чинили тесты после каждого чиха в UI? Или, может быть, несколько недель ждали, пока в дизайн-систему добавят недостающий тег или семантику, чтобы вообще начать писать свой UI-тест? Если вы хоть на один вопрос ответили «Да», эта статья для вас. Давайте навсегда покончим с этой рутиной и займемся более креативными задачами!

Цель статьи — НЕ представить очередной фреймворк написания UI-тестов для приложений на Android, а упростить их написание с помощью всем знакомого Page Object. Мы будем прятать рутину поиска нужных компонентов и одновременно повышать устойчивость тестов к изменениям. Всё для того, чтобы тесты стали удобнее, надёжнее и проще поддерживались.

Меня зовут Дмитрий Омельченко, я Android-разработчик в Райффайзенбанке. Несколько лет назад мы с командой начали внедрять автоматизацию тестирования в приложение online-банка, и за это реализовали несколько интересных решений, об одном из которых хочу вам рассказать.

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

Привет, Хабр! Меня зовут Вадим, я уже много лет в тестировании и сейчас работаю Head of QA в Альфа-Банке (Беларусь). За эти годы я успел поработать с десятками инструментов, написать сотни тест-кейсов и... потратить неприлично много времени на рутину, которую можно было автоматизировать ещё вчера.

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

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

В сегодняшней статье расмотрим Эффективность тестирования

Какими метриками измерить эффективность тестирования? 

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

Тестирование на Swift долгие годы держалось на трех китах: XCTest, сторонние библиотеки и собственная смекалка. Но на WWDC 24 Apple представила новый, современный фреймворк — Swift Testing, который предлагает концептуально новый подход к тестированию.

Меня зовут Кирилл Гусев. Я мобильный разработчик в ОК. В этой статье я расскажу о том, какие возможности предоставляет Swift Testing и как мы планируем их применять в ОК.

Моя вторая статья — анализ сетевых запросов MAX и почему этот анализ — моё самое большое разочарование! Не ожидал я такого конечно, но описал все как есть.

В своей первой статье «Разрешения MAX для Android. Cравниваем с Telegram и WhatsApp*» я сравнил резрешения, которые запрашивает приложение MAX для Android с разрешениями, которые запрашивают Telegram и WhatsApp.

18 сентября вышла новая версия MAX — 25.11.0 и вы знаете, произошло то, чего я не ожидал. MAX стал запрашивать 50 разрешений, вместо 59, т. е. на 9 меньше!

Давайте посмотрим, какие же разрешения убрали разработчики.

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

В этой статье расскажу, как мне удалось «влезть» в плагин GitHub Copilot, обойти ограничения проприетарного инструмента и научить его помогать писать unit-тесты буквально в пару кликов. Думаю это будет полезно тем, кто хочет узнать как влезать в работу сторонних плагинов, ускорить написание тестов и тем, кто ищет способы прокачать работу с ИИ-помощниками в своих проектах.

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

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

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

Этот чек-лист я написал для себя, чтобы протестировать на проекте push-уведомления для iOS и Android, и возможно он может быть будет полезен другим тестировщикам, что бы упростить немного работу, а также уточнить или добавить этот чек-лист в комментах (а я дополню публикацию)

Привет! Я Алексей, старший тестировщик в департаменте разработки ЮMoney. С 2018 года провожу собеседования на позицию QA-инженера. В этой статье поделюсь своим опытом и взглядом команды на этот процесс. Расскажу, как мы готовимся к интервью, почему кандидаты с идеальным резюме могут не подойти и на что мы смотрим, принимая итоговое решение. Ещё вы узнаете, почему иногда мы предлагаем кандидату не ту должность, на которую он претендовал.

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

Меня зовут Артём Хюппенен, я инженер по тестированию в YADRO. В статье я поделюсь техническими деталями собственного фреймворка: как мы выбирали технологии, что оказалось удачным и как теперь любой член команды может быстро автоматизировать тесты для сложных CLI-приложений. В конце статьи — ссылка на репозиторий, чтобы посмотреть архитектуру решения. 

Привет, Хабр! Меня зовут Иван Калашников, я занимаюсь автотестированием в Инфовотч.

В мире web и тонких клиентов по-прежнему приходится тестировать классические приложения: Office apps, Explorer, Telegram, WhatsApp. Сегодня для примера мы возьмем WhatsApp.

Погрузившись в автоматизацию ручных кликов в приложениях Windows с помощью Python, я попробовал несколько известных библиотек, каждая из которых поодиночке оставляла ощущение «чего-то не хватает». PyAutoGUI не видит скрытые элементы, плохо находит элементы с экранами разного масштаба и разрешения, а pywinauto требует разбирать дерево элементов UIA (Microsoft UI Automation), которого может попросту не быть.

В этой статье разберём, как объединение этих инструментов позволяет обойти ограничения каждого и надёжно автоматизировать windows-приложения. Комбинация UI-ориентированных (pywinauto, Win32/UIA) и image-based (PyAutoGUI) техник остаётся самым гибким способом тестировать Windows-приложения. Но чтобы смесь действительно работала, нужны: сравнение бэкендов, явные ожидания, DPI-awareness.

Мы пройдем через ряд мини-кейсов — от кликов, поиска, отправки сообщения, до чтения текста с экрана и выясним, как справляется связка Python-библиотек.

Тест-кейс тест-кейсу рознь!

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

Доработка кейсов своими силами (силами автотестеров) в процессе автоматизации – это сизифов труд.

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

На первом же проекте это дало очень мощный положительный эффект не только для нас, автотестеров, но и для самих ручных тестировщиков: позволило ускорить процесс вникания в суть кейса разработчиками автотестов, а также сократило время адаптации для новых ручных тестировщиков до 2-х недель против 3-х месяцев.

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

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

Итак, начнем урок.

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, ка��:

— подключить минимальный набор инструментов для диагностики;
— улучшить читаемость отчётов;
— использовать кастомные ассерты для более информативных ошибок;
— выбрать подходящие репортеры под разные роли в команде;
— и даже применить AI для автоматического анализа падений.

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

Меня зовут Настя Неводчикова, я системный аналитик в KODE. В этой статье я хочу поделиться опытом работы с бинарными форматами сериализации, а именно с Protobuf, и рассказать, с какими проблемами мы столкнулись в процессе аналитики и тестирования, а также как их решали.

Исходные условия: у нас было мобильное приложение, написанное на Objective-C (iOS) и Java (Android). Цель — переписать его на современный стек: Swift и Kotlin. Дополнительно нужно было сделать редизайн приложения и обновить бэкенд: поднять Java с 6 до 21. Приложение общалось с бэкендом по HTTP и использовало Protobuf для сериализации данных.

Что важно — никакой документации на существующее приложение не было. У нас была лишь тестовая сборка и сервер с логикой. Поэтому перед стартом разработки нужно было:

Всем привет!

Я, на свой страх и риск, решил установить себе MAX и посмотреть, а что же происходит после установки? По итогам моего исследования будет минимум 2 статьи.

Это - первая статья. В ней я сравню разрешения, которые запрашивает приложение MAX для Android с разрешениями, которые запрашивают Telegram и WhatsApp.

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