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

Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.

За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше. 

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

Redis всё чаще встречается в вакансиях для QA, и понимание его работы становится полезным навыком для тестировщика.

В статье простым языком объясняется, что такое Redis, где он используется, чем отличается от реляционных баз данных и почему он работает быстрее SQL.

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

Подойдёт для подготовки к собеседованиям и для работы на реальных проектах.

Привет, я Максим Королев из Петрович-Теха, цифрового партнера сети строительных магазинов «Петрович». Компания специализируется на продаже стройматериалов, комплектации крупных объектов и комплексном обслуживании, включая доставку и подъем на этаж. В первой статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM, во второй — как вынесли бизнес-логику «Дежурного» в CORE и подключили MAX.

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

Недавно ISTQB выпустили новую версию сертификации Certified Tester AI Testing v2.0.
Я посмотрел обновлённый syllabus и решил разобрать, что там изменилось, куда сместился фокус и насколько новая версия действительно соответствует тому, что сейчас происходит в мире AI testing.

Это была пятница, шесть вечера. Я сидел перед монитором и чувствовал себя следователем, который зашёл в тупик.

Три часа назад я нашёл странное поведение в приложении. Открыл Jira, но пока заполнял поля — мысль ушла. На рабочем столе уже лежало 15 скриншотов с именами вроде «Снимок экрана 154312.png». Я открыл их наугад, но уже не помнил, к какому запросу какой относится.

«Я потерял контекст». Баг есть, даже помню, как воспроизвести. Но чтобы восстановить цепочку «действие → реакция сервера → скриншот → вывод» — нужен ещё час.

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

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

Меня зовут Александр. Я перепробовал Jira, Confluence, Notion и просто папки на диске. Всё либо медленно, либо хаотично, либо зависит от интернета. Поэтому я собрал свой локальный редактор — под себя, под тестирование. Делюсь историей и кейсом.

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

В нашей компании по тестированию ПО на аутсорсе мы постоянно сталкиваемся с тем, что формат сотрудничества диктует инфраструктура заказчика. На одном проекте нас ждет построенная по всем канонам CI/CD, а на другом полное отсутствие VCS. В таких условиях легко потерять контроль над качеством нашей работы.

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

Когда мы заходим на проект, то почти всегда встраиваемся в существующую экосистему.

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

Работая исключительно на стороне клиента, мы не можем внедрить обязательное внутреннее ревью кода, настроить свои стандарты CI/CD-пайплайнов или, например, использовать привычные нам инструменты отчетности.

Бывает ситуации и сложнее. Например, у клиента есть CI/CD, но из-за требований безопасности им нельзя подключать внешние раннеры. Бывает случаи, когда у клиента нет своего CI/CD. Поднять его у себя они не могут (нет на это ресурсов, людей или того и другого), а использовать публичные или даже приватные облака запрещает какое-нибудь внутреннее соглашение.

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

Наш стек

Чтобы обеспечить стабильность, мы развернули внутреннюю связку: Self-hosted GitLab + GitLab CI + GitLab Pages.

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

В условиях существенного троттлинга WhatsApp* и Telegram, а также активного преследования VPN и proxy, имеет смысл заранее позаботиться об альтернативах. В этой статье мы рассмотрим три мессенджера, которые могут стать заменой: набирающий популярность IMO, внезапно ставший хайповым KakaoTalk и получивший недавно апгрейд Телемост.

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

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

В рамках этого сценария мы проверяли наличие самых востребованных функций:

• текстовые чаты (личные и групповые),

• отправку голосовых сообщений,

• аудио- и видеозвонки (как индивидуальные, так и групповые),

• обмен фотографиями, файлами и документами,

• использование стикеров, эмодзи и анимаций.

Помимо этого мы проверили наличие десктопных версий приложений — что важно при общении с коллегами по работе. Мы также убедились, что все три мессенджера доступны не только в российском App Store и Google Play, но и в зарубежных (возможно вы общаетесь с друзьями или заказчиками из других стран). Все три приложения были скачаны впервые. Все три приложения работают в России без VPN.

Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? UI написал «подтверждено», но UI иногда врёт — проглоченная ошибка, откаченная транзакция, очередь, которая молча дропнула сообщение.

Классическое решение некрасиво: нужно подключить ORM или низкоуровневый драйвер базы данных внутри тестового харнеса, управлять отдельными учётными данными, писать SQL-ассерты вручную и надеяться, что схема не изменится. Работает. Но это накладные расходы на поддержку, которые вы платите за каждый тест.

Сейчас есть паттерн лучше. И в нём ноль SQL с вашей стороны.

Что если один AI-агент сможет делать обе половины — управлять браузером при оформлении заказа и затем переключиться в базу данных для проверки записи — используя два MCP-сервера?

Именно это разбирается в статье:

Всем привет! Меня зовут Артем. Я Android QA Engineer в команде Банки.ру.

Было ли у вас такое, что unit-тесты в проекте есть, но на практике ими почти никто не пользуется? Разработчики их пишут, но для QA это “что-то где-то в коде”: нельзя нормально посмотреть результаты, оценить покрытие или использовать в регрессе.

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

Всем привет! Меня зовут Оля Ермолаева, я работаю в сфере обеспечения качества ПО уже больше 17 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха, агротеха и ритейла. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге лет 10 назад ушла с головой в менеджмент и веду свой небольшой ТГ канал про тестирование, менеджмент и всё, что с этим связано.

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

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

Сейчас TMS на рынке условно можно разделить на два подхода.

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

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

В новом релизе DoQA 4.0 как раз добавили сценарий с запуском автотестов прямо внутри TMS. Давайте разберем, как это ребята реализовали.

Пока оперативка дорожает из-за LLM, в банках очень много ручного тестирования. Покрытие автотестами не очень высокое, потому что их тоже надо писать с AI, а ИБ закономерно запрещает доступ к внешним облачным моделям. Мы не можем просто взять закрытый код банка и скормить его публичной нейросети.

По большей части на ручные тесты уезжают сверка логики процесса (end-to-end-сценарии) и тесты UI.

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

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

Playwright 1.59 — не очередное инкрементальное обновление. Это заявка на то, куда движется автоматизация тестирования, и это направление глубоко агентное. Если вы ждали, когда инструменты догонят AI-driven воркфлоу, о которых все говорят, этот релиз закрывает разрыв.

Разберём каждую крупную фичу и, что важнее, как каждую из них можно применить немедленно.

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

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

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

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

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

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

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

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

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

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

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