Методы, советы, опыт
Можно ли сделать e2e тесты мощным инструментом раннего отлова багов, не потопив при этом CI и не всем не разругавшись?
Рассказываю, через что пришлось пройти, чтобы релизы были спокойные, пайплайны — зеленые, разработчики — довольные.
Как мы это внедряли, сколько сопротивления получили и что из этого выжило спустя четыре месяца.
Часто кажется, что тестирование пуш-уведомлений – одна из самых простых задач: отправил, получил, кликнул. Если текст отображается корректно, и ссылка открывается, задача считается выполненной.
Однако в финтехе цена ошибки измеряется не только временем, но и реальными деньгами. Для нас, как для команды обеспечения качества, пуш-уведомления – это не просто текст на экране, это обещание пользователю. Обещание того, что клик приведет его к решению задачи быстро, безопасно и без потери контекста. Сломанный диплинк в уведомлении о волатильности актива может привести к тому, что трейдер не успеет закрыть позицию и потеряет часть депозита. Если навигация ломается, пользовательский сценарий прерывается, и клиент остается один на один с проблемой.
В Centicore Group мы подходим к проверке диплинков и пушей не как к сухой технической задаче, а как к части пользовательского опыта. Разберем, где скрыты основные риски и как выстраивать мышление качества в этом направлении.
А еще мы с командой решили провести небольшой конкурс. Мы подготовили для QA-инженеров виз с вопросами - отличная возможность проверить свои знания и просто интересно провести время за чашкой кофе (или в перерыве между прогоном регрессии). Взамен - приятный бонус в виде подарков для тех, кто успешно пройдет тест.
Об условиях конкурса и подарках можно узнать по ссылке - Квиз для QA
А теперь к контексту
Диплинк, как контракт между бизнесом и пользователем
Диплинк в инвестиционном приложении выполняет роль навигационного контракта. Когда клиент видит уведомление о смене цены или статусе заявки, дизайн системы предполагает, что тап по нему сразу откроет экран для принятия решения.
Проблема возникает, когда мы рассматриваем диплинк исключительно как технический URL. На деле это сложный объект с метаданными: идентификаторами инструментов, параметрами сессии, источниками триггеров. Фокус тестирования меняется: мы проверяем не только работоспособность ссылки, но и ее соответствие текущему контексту.
Важнее проверить пограничные состояния, например, что увидит клиент, если актив уже делистингован, а чат поддержки временно недоступен? В нашей практике мы заменяем технические ошибки на понятные заглушки: вместо белого экрана или кода 404 пользователь видит сообщение «Актив больше не торгуется» или «Раздел временно недоступен» с предложением вернуться в портфель или написать позднее.
Задача качественного тестирования навигации – минимизировать риски «тупиковых» сценариев. Если целевой экран недоступен, система должна мягко перенаправить пользователя, объяснив причину и сохранив рабочий контекст. Это прямое уважение к его времени.
Матрица состояний: уважение к контексту
Одна из самых сложных задач при тестировании пушей – учет состояния приложения в момент клика. Пользователь взаимодействует с устройством по-разному, и навигация должна адаптироваться. Мы выделяем несколько ключевых сценариев:
Если вы когда-нибудь пытались просмотреть сетевые запросы десктопного или мобильного приложения через HTTPS-прокси, то наверняка сталкивались со странной ситуацией: прокси настроен, корневой сертификат установлен и доверен, системный прокси прописан, а в списке запросов пусто. Или приложение начинает выдавать ошибку сразу после включения перехвата.
Ниже будет описан набор реальных сценариев, со схемами работы на сетевом уровне и примерами того, как это выглядит в прокси-приложении. Для этого я использую Сольпугу и несколько демо-приложений с разными условиями.
По мере роста UI-регрессии сложнее всего становится управлять не тестами, а их окружением: состоянием приложения, ответами backend и воспроизводимостью сценариев. В статье разбираю архитектуру, которая связывает тест-кейсы QA, mock-профили, XCUITest и XcodeBuildMCP в единый процесс — от подготовки сценария до запуска в CI.
В навигации есть ситуации, которые невозможно честно проверить, не выходя в «поле». Можно написать код, прогнать тесты, собрать метрики — и всё равно получить кейс, когда в жизни геопозиция «зависла», позиция «улетела», а ведение по маршруту начинает жить своей жизнью.
Мы уже рассказывали, почему геопозиция бывает нестабильной и как 2ГИС помогает пользователям в такие моменты. Сегодня выпустили ещё несколько обновлений для улучшения навигации в зонах c нестабильной геопозицией — в том числе внедрили сенсорную (инерциальную) навигацию. В этой статье расскажем, как нам в этом помогли полевые проезды.
Дисклеймер: я делаю сервис аренды Mac mini (ссылка в профиле), поэтому тема мне близка профессионально. В статье нет ссылок на него и не будет рекомендаций его выбрать — только разбор всех путей, которыми пользуюсь сам и которые видел у коллег.
Привет, Хабр! Я Оля Шишенина, отвечаю за обучение и развитие сотрудников VK. Хочу рассказать про внутреннее мероприятие для инженеров, которое мы провели этой весной: Фиксатон VK — трёхдневный марафон по багфиксам, на котором разработчики чинили баги не только в своих командах, но и в смежных продуктах VK. Решения прошли многоэтапный фильтр от общего пула задач, через проверку кода, QA-ревью при подготовке к релизу.
Победители фиксатона получили Nintendo, Playstation, а главному победителю по баллам в индивидуальном зачёте мы подарили Niva Legend — это отличная машина для того, кто любит фиксить и тюнинговать.
Перед первой публикацией разработанного мной приложения WeCount я был уверен, что главная причина возможного отказа — ошибки в коде или проблемы в пользовательских сценариях. На практике оказалось наоборот: за всё время App Review к функциональности приложения не возникло ни одного вопроса. Почти все замечания касались исключительно регистрации пользователя.
За два месяца переписки, нескольких отказов подряд и телефонных разговоров с командой App Review, этап регистрации был полностью переписан. В этой статье я расскажу, какие выводы сделал, и почему первоначальная архитектура оказалась ошибочной.
Опыт весны/лета 2025 года
В этой статье расскажу, как устроен отбор, чему действительно учат на курсе, как организовано обучение и насколько полезной оказалась обратная связь от преподавателей и проверяющих. Отдельно поделюсь опытом прохождения всех этапов трудоустройства: от приглашения на технические собеседования до получения оффера.
Мобильное приложение может стабильно проходить тесты и всё равно падать у пользователей в сценариях, которые команда не успела предусмотреть.
В статье разберём, как связать Firebase Crashlytics, Sentry и Datadog во Flutter‑приложении, чтобы собирать ошибки с контекстом, быстрее находить причины сбоев и видеть проблемы с производительностью до того, как они станут массовыми.
Привет, Хабр! Меня зовут Богдан Бурков, я старший инженер по тестированию в мобильном приложении для продавцов Ozon Seller. В этой статье я хочу поделиться историей, как мы с коллегой, ведущим инженером по тестированию Владиславом Поповым (привет, Влад!), улучшали наш релизный процесс и что у нас из этого получилось.
Мы уже оптимизировали ручные проверки и увеличивали покрытие автотестами, но релизное тестирование всё равно занимало почти рабочий день. Подробнее об этом опыте можно прочесть в статье другого коллеги. Мы же решили копнуть глубже — не в сами тесты, а в процессы вокруг них. Выписали всё, что повторяется от релиза к релизу, отметили, какие действия блокируют переход на следующие этапы, оценили, сколько времени уходит на рутину, и выбрали те задачи, которые проще всего перенести в CI. Так мы нашли главную причину потерь времени и поняли, куда двигаться дальше.
В статье расскажу, что именно мы автоматизировали, что получилось не сразу и как в итоге сократили релизное тестирование примерно с семи до четырёх часов.
Большие языковые модели давно вышли за пределы «помоги дописать функцию». Они доступны всем — и злоумышленник тут не исключение. Отсюда практический вопрос, который нас и интересовал: может ли LLM самостоятельно, без человека, атаковать мобильное приложение, и если да — во сколько это обойдётся.
Из всего списка рисков мы взяли один конкретный сценарий: внедрить в приложение вредоносный код так, чтобы после пересборки оно осталось рабочим и его можно было раздавать живым пользователям. Проверяли на Android.
Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать.
Поэтому я хочу показать на конкретном примере из жизни, где еще несколько лет назад пришлось бы делать красивый отчет в ручную, а теперь его делает робот за пару минут. Возможно, это вдохновит вас тоже попробовать сделать нечто похожее =))
SonarQube подключен, дашборд есть, анализ запускается на каждый MR, но никто не пользуется. В таком случае проблема не в инструменте. Проблема в том, что между «Sonar работает» и «Sonar приносит пользу» — пропасть из-за отсутствия договорённостей. Я видела это на нескольких проектах и расскажу, что конкретно превращает декоративный дашборд в работающий механизм контроля качества.
Статья будет полезна QA, разработчикам и тимлидам, у которых SonarQube уже есть, но результаты анализа живут и ни на что не влияют.
Когда проект растёт, дольше всего начинают тянуться самые «тяжёлые» проверки – UI-тесты. Один-два модуля поменял, а CI всё равно гоняет сотни тестов на эмуляторах и ждёт их десятки, а то и сотни минут. Знакомо?
Это третья, финальная статья цикла о том, как мы в Циане перешли от полного прогона всех проверок к выборочному с помощью Impact-анализа. В первой части я показывал, как мы ускорили статические анализаторы, во второй — как в два раза сократили unit-тесты, научившись обходить граф Gradle-модулей. В заключительной части я расскажу, как у нас на проде реализован выборочный запуск UI-тестов.
За последние десять лет роль тестирования изменилась гораздо сильнее, чем за предыдущие двадцать. Если раньше QA воспринимался как последний рубеж перед релизом, то сегодня инженеры по качеству участвуют в проектировании требований, помогают команде выстраивать процесс поставки изменений и зачастую становятся теми, кто первым замечает, что система начинает терять устойчивость.
При этом вокруг технического долга до сих пор существует одна довольно устойчивая иллюзия. Стоит в команде заговорить о замедлении разработки, росте количества регрессий или усложнении релизов, как почти неизбежно звучит предложение: «Нужно усилить тестирование». Иногда под этим понимают автоматизацию, иногда — увеличение покрытия тестами, иногда — дополнительные проверки перед релизом. Формулировки могут отличаться, но логика остаётся одной и той же: если система становится сложнее, значит, её нужно лучше тестировать.
На первый взгляд такая логика выглядит вполне разумной: если система становится сложнее, значит, её нужно лучше тестировать. Проблема в том, что тестирование не устраняет причину этой сложности. Оно лишь позволяет раньше заметить её последствия.
Мы привыкли воспринимать технический долг как инженерскую проблему, которую можно постепенно уменьшить: провести рефакторинг, переписать несколько сервисов, улучшить покрытие тестами. Но тестирование вообще не находится в той точке жизненного цикла, где этот долг появляется. Оно сталкивается с ним значительно позже, когда архитектурные решения уже приняты, зависимости между компонентами сформированы, а сложность системы стала объективной характеристикой продукта.
Какова ситуация в мобильном тестировании в 2026-м году?
На связи Ильнур – ведущий тестировщик: начал свой путь в ИТ 10 лет назад как специалист технической поддержки. Со временем понял, что хочу не просто «чинить», а понимать, как всё устроено. Так я пришёл в тестирование и уже через год стал тимлидом команды.
На протяжении следующих 5 лет участвовал в запуске более 10 приложений – от MVP до многомиллионных. Я учился на ошибках, пропускал через себя сотни релизов, «съел собаку» в ручном тестировании, понял, как работают платформы, сети, железо. Хочу поделиться своими мыслями о мобильном тестировании как человек, который знает сферу изнутри.
Вообще, идея была автоматизировать процесс проведения анализа и извлечения всей необходимой информации из вредоносного APK файла. Ряд программ уже существует в компьютерном мире, однако я понял для себя, что нет единого ящика, который бы мог держать в себе все необходимые инструменты и выполнять анализ более качественно и развернуто, ну и, соответственно, работать по цели.
Если коротко, то APEX — программа, которая пригодится всем, кто работает с Android-приложениями: тестировщикам, разработчикам, специалистам по безопасности и просто в случае необходимости проверить свой телефон на активность.
Она позволяет глубоко анализировать APK-файлы и установленные приложения прямо с телефона, без необходимости куда-то их отправлять, также это поможет даже в том случае, если ваши (встроенные или сторонне установленные) антивирусы не задетектили подозрительное или вредоносное приложение.
Привет, Хабр! На связи снова Максим из ATI.SU.
В прошлых статьях мы разобрались, как искать логи и креш‑отчёты на iOS‑устройствах — и делали это вручную. Этот навык остаётся базовым на проекте любого размера: без него невозможно понять причину сбоя. Но есть и вторая часть работы — сами проверки, то есть прогон пользовательских сценариев. Пока приложение небольшое, их можно прокликивать руками. По мере роста количество однотипных проверок увеличивается, и повторять их вручную перед каждым релизом становится всё дороже.
Возникает логичный вопрос: можно ли автоматизировать именно эту рутину — прогон сценариев, — чтобы проверки проходили без нашего участия, а нам оставалось разбираться с причинами сбоев, если такие возникнут? Здесь нам помогут нативные автотесты на XCUITest. Они позволяют системно, а не от случая к случаю, прогонять пользовательские сценарии, отслеживать падения и проверять стабильность. А когда тест краснеет, в дело снова вступают логи и креш‑отчёты — те самые, что мы научились искать в предыдущих статьях.
Этой статьёй мы открываем цикл о UI‑тестировании iOS приложений. Начнём с основ: разберёмся, какое место UI‑тесты занимают в пирамиде тестирования, познакомимся с инструментами и постепенно перейдём к построению устойчивых тестов с применением проверенных паттернов.
19 июля 2024 года в 04:09 UTC CrowdStrike выкатил обновление контентного файла для своего антивируса Falcon Sensor. За следующие 78 минут 8,5 миллиона Windows-машин по всему миру ушли в бесконечный BSOD-loop. Встали аэропорты (>5000 отменённых рейсов только в США), больницы, банки, биржи, 911-диспетчерские. Прямой ущерб корпоративных клиентов — около $5,4 млрд по оценке Parametrix; одна только Delta потеряла ~$500 млн.
Самое неприятное для нас, инженеров: баг был тривиальный. Не гонка потоков на проде под нагрузкой, не хитрый UB в компиляторе — а банальный выход за границу массива, который ловится unit-тестом за пять секунд. Ниже — как именно это произошло и почему ни один уровень защиты не сработал.