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

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

В этот момент прокси-инструменты вроде Proxyman начинают играть совсем другую роль. Это уже не просто «посмотреть запросы», а полноценный слой управления трафиком.

Меня зовут Станислав, я Test-инженер в KODE, в этой статье разберу, как использовать Proxyman Scripts не как вспомогательную фичу, а как инструмент автоматизации тестирования.

Всем привет! Меня зовут Юля Трусова и я тестировщик. А ещё я лидирую под ключ одно из самых крупных и древних комьюнити в Авито — QA Community. В этой статье я расскажу про свой подход к теме, поделюсь важными вехами в становлении комьюнити и с удовольствием почитаю про ваш опыт в комментариях.

Привет, хабровчане! С вами снова Евгений Иванов, QA-lead в компании Fix Price. В этот раз поделюсь с Вами опытом внедрения автоматизации для гибридного мобильного приложения на Android. 

У этого решения есть свои плюсы и минусы, и мы продолжаем работать над его развитием. Но уже сейчас понятно: оно приносит реальную пользу команде во время регрессионных и предрелизных прогонов. Расскажу подробнее, как мы собрали связку Playwright + Appium + WebdriverIO и что из этого вышло.

Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».

В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM

примеры таблиц, схемы и чек-лист для QA

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

Если честно, меня удивляет, что такая позиция в мире современного ИТ всё ещё существует. Так что я решил собрать аргументы и объяснить, почему самотестирование – важная часть рутины разработчика. Будет интересно послушать в комментария аргументы тех, кто с этим не согласен. 

При разработке мобильных приложений на 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.