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

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

Для решения этой проблемы я написал пакет yx_virtual_device, который позволяет симулировать экраны различных устройств прямо во время разработки, не выходя из запущенного приложения. В этой статье — о том, что умеет этот пакет, как с ним работать, а также почему было сложно подружить его с Flutter и как в итоге это удалось сделать.

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

Прокси — один из основных инструментов в арсенале QA-инженера. Charles Proxy, Fiddler и Proxyman давно стали стандартом для анализа и изменения сетевого трафика в процессе ручного тестирования. Их принцип работы хорошо известен и подробно описан во множестве материалов.

Однако возникает вопрос: как использовать подобные возможности в UI-автотестах? Как перехватывать или мокать трафик в автоматизированных сценариях?

Привет, Хабр! Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.

Привет, Хабр.

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

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

Поэтому решил поделиться своей насмотренностью на этот счет 👇

Привет, Хабр! На связи снова Максим из ATI.SU. В прошлой статье мы научились собирать логи на iOS устройствах разными способами и теперь для нас не вопрос разобраться, почему кнопка не нажимается, а данные не грузятся.

Но бывают ситуации куда страшнее. Вы запускаете приложение, а оно... тут же исчезает. Или вы работали в приложении, раз... и вы видите домашний экран. А еще приложение может так зависнуть, что помогает только полная перезагрузка самого устройства. Все это — его величество креш (a.k.a. краш, крэш, crash, вылет, сбой, падение, аварийное завершение).

Если привести аналогии, то логи — это жалобная книга, а креш‑отчет — это заключение судмедэксперта. В нём написано точное время смерти, причина и состояние памяти устройства в последний момент жизни приложения.

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

Как устроен процесс собеседования QA-инженера в 2026 году? Из каких этапов он состоит и чем интересуются интервьюеры на каждом из них? В этом гайде я разложил всё по полочкам: что спрашивает HR (и как он оценивает ваши ответы), какие блоки теории нужно повторить manual-инженерам, а какие — automation-инженерам на Java, и как проходит секция с задачами на логику и лайвкодингом.

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

Вы открываете приложение, чтобы быстро проверить баланс или забронировать стол, и тут же получаете в лицо: «Вам нравится наше приложение? Оцените нас!». Ваша реакция? В лучшем случае - машинальное нажатие на крестик, в худшем - удаление. Моя личная боль - открываешь банковское приложение для оплаты на кассе по СБП и получаешь аж три баннера один за другим на экран. Я не хочу прямо сейчас оформить кредит, не хочу оценивать ваши продукты. Я только открыл приложение, я покупки оплатить хочу. И такое поведение если уж не каждый запуск, то каждый второй точно.

В 2026 году Apple и Google стали еще жестче фильтровать накрутки, а пользователи - еще чувствительнее к прерыванию их «флоу». Тем не менее, рейтинг 4.9 - это не магия, а математика, психология и вовремя вызванный системный метод.

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

Рынок QA больше не про «быстрый вход» и простые решения. Вакансий меньше, требований больше, а старые советы не работают. В статье — приземлённый алгоритм, который помогает начать путь от рынка, а не от обещаний, и не потратить год на подготовку без выхода к офферам.

Как тестировать несколько мобильных приложений в одном «Appium‑проекте». Показываю архитектуру фреймворка, запуск тестов через аннотации, потокобезопасный контекст и подключение новых приложений без дублирования кода.

Помните времена, когда пуш-уведомление реально что-то значило? Телефон вибрировал, и ты точно знал: случилось что-то важное. Такси подъехало. Деньги списались. Начальник написал что-то срочное (ладно, обычно не срочное, но хотя бы по делу).

Это был 2016 год.

На дворе 2026-й. Шторка уведомлений среднего пользователя превратилась в мусорный бак, куда маркетологи сбрасывают свои KPI с маниакальным упорством.

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

Поиск работы в IT часто выглядит похожим образом: десятки откликов, постоянные собеседования, новые команды, разные проекты и условия.

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

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

В результате решение об оффере принимается почти вслепую.

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

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

Поделюсь основными из них, надеюсь, что всем будет полезно 👇

Привет! Я Ангелина Архипова, тимлид QA в Авито. Это вторая часть статьи про развитие QA, ранее я разобрала этапы взросления QA-инженера — от охотника за багами до лидера, который формирует культуру качества в команде.

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

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

Вы попросили ChatGPT добавить скидку 10% на заказы больше $100. Он выдал 40 строк кода. Скидка работает - проверили на заказе в $150, получили $135. Закоммитили.

Чего вы не заметили: модель переписала функцию расчёта цены целиком. Не потому что нужно было. Просто так получилось - LLM не "редактирует" код, он генерирует новый текст на основе вашего промпта и контекста. В процессе он изменил порядок вычисления налога. Заказы меньше $100 теперь считают налог дважды. Товар за $10 стоит $10.80 вместо $10.50. Вы узнаете об этом через три недели, когда клиент напишет в поддержку.

Браузер — основная рабочая среда QA-инженера, но стандартные DevTools не всегда удобны для повседневных проверок. В этой статье собраны 10 полезных расширений Chrome, которые помогают быстрее проверять верстку, отслеживать визуальные изменения, анализировать ссылки, работать с API и генерировать тестовые данные. Подборка ориентирована на практическое использование и подойдёт как manual-, так и automation-QA.

Большинство разработчиков думают об офлайн-режиме в последнюю очередь - когда приложение уже готово, дизайн согласован, а PM давит на дедлайн. В результате пользователь видит белый экран, зависший спиннер или, что хуже - молча потерянные данные. Эта статья про то, как выстроить честный UX для состояний без сети: от психологии тревоги до кода с экспоненциальным откатом, от визуального языка ошибок до стратегий разрешения конфликтов. Всё это пригодится при разработке любого мобильного или веб-приложения, которое работает в условиях нестабильного соединения - а таких большинство.

Всем привет! Меня зовут Ира Карачакова, я тестировщик в сервисе бронирования отелей Отелло.

В этой статье рассказываю, как у нас в команде выстроился процесс работы с нестабильными фронтовыми e2e-тестами: от простых перезапусков в CI до системы алертов, карантина и отслеживания стабильности.

Это не инструкция и не универсальный рецепт. Скорее история эволюции процессов в живом продукте: с какими проблемами мы сталкивались, какие решения пробовали и какие выводы сделали. Возможно, статья подкинет вам идеи и ориентиры: какие сигналы о flaky-тестах важно отслеживать, как не терять нестабильные тесты из виду и как со временем превратить борьбу с ними в управляемый процесс. 

Если вы разрабатываете iOS-приложение с виджетом, Watch-компаньоном (это приложение для Apple Watch, которое работает в паре с основным приложением на iPhone) или Share Extension - рано или поздно вам придётся передавать данные между процессами. App Groups - стандартный механизм для этого, и на первый взгляд он прост: добавил capability, написал UserDefaults(suiteName:), поехали. Но именно эта кажущаяся простота и создаёт проблемы. Данные лежат в незашифрованном контейнере, любое приложение из вашей команды может их прочитать, а валидация входящих данных почти никогда не делается. Давайте же рассмотрим, как правильно настроить App Groups, что реально можно туда класть, какие риски существуют и как организовать безопасный обмен (в том числе с примером передачи токена авторизации между приложением и виджетом).

«Ты будешь единственным тестировщиком на проекте», — услышал я на знакомстве с командой. Ничего страшного, с кем не бывало? «У нас не было постоянного тестировщика, нужно выстраивать все процессы с нуля», — добавил мой будущий тимлид. А вот это уже интереснее. 

Меня зовут Илья, я отвечаю за качество A/B‑платформы в Точка Банке. Сегодня я хочу рассказать, как тестировщику воспользоваться безграничной властью с пользой для всех (и немного для себя).

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

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