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

Статья Галины Шайдуровой

Психология тестировщика: почему критическое мышление – это суперсила

Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.

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

Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберем, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход, и как нестандартное мышление спасает проекты (и иногда ночной сон).

В этой статье мы проведем обзор современных инструментов и подходов для тестирования мобильных приложений на примере приложения КриптоАРМ Mobile под Android. Подробно расскажем о настройке окружения для создания тестов, а также разработаем Docker-контейнер, который обеспечит удобный запуск тестов. Кроме того, мы рассмотрим процесс автоматизации тестирования и его интеграцию в CI/CD, что позволит упростить и ускорить процесс разработки и тестирования приложений.

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

Привет, Хабр! В России набирает популярность новый подход к созданию пользовательских интерфейсов — Backend Driven UI (BDUI). В нём сервер задаёт структуру и поведение интерфейса, а приложение просто отображает его на экране.

BDUI уже используют в своих приложениях многие коллеги из индустрии. Меня зовут Елена Зеликсон, я старший инженер по тестированию в VK. О том, какие преимущества у этого решения и как его применять, подробнее расскажу в этой статье.

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

Привет! Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

В этой статье я не только разберу основные нефункциональные проверки, но и расскажу, что происходит с приложением в моменты, когда, например, вы сворачиваете его или выключаете экран – не взаимодействуете с телефоном. Часть тестов применима к обеим платформам, а некоторые актуальны только для Android или iOS. Примеры всех багов взяты из личного опыта тестирования.

Из-за экономических санкций и удаления приложений из App Store и Google Play российские организации были вынуждены отойти от привычных всем репозиториев, предоставив злоумышленникам больше возможностей для обмана пользователей: загрузка и обновление приложений по внешним ссылкам даже для банковских клиентов стали привычными. Более того, пользователи ищут более удобную альтернативу известным приложениям

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

Эти угрозы требуют от специалистов по безопасности постоянного анализа и разработки контрмер. Для этого необходимо знать, какие инструменты и методы используют злоумышленники. Арсенал атакующих в общем случае выглядит так: вредоносное ПО, фишинговые письма и эксплойты.

Не только рэп и андеграунд рождаются в Газгольдере — теперь там соберутся и те, кто «качает» процессы тестирования. Как инженерный подход помог создать востребованный инструмент для QA-команд, можно ли с нуля построить автоматизацию оборудования на Bash и почему отчетность — это не про таблицы, а про доверие к процессу? Об этом и не только поговорим 19 июня на QA-митапе от YADRO в Газгольдер Event Hall — живо, с практикой и участием экспертов из Avito, Т-Банка и YADRO. Регистрируйтесь и присоединяйтесь — онлайн или оффлайн.

Для тестирования мобильных приложений придумано множество эвристик и мнемоник. В этой статье расскажем об одной из полезных мнемоник для тестирования мобильных приложений.

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

Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано...

Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды.

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

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

Привет, Хабр. Меня зовут Иван Фитискин, я senior-QA-инженер в Профи.ру. Работаю здесь уже семь лет, а пришёл сразу после университета — и сразу на должность тестировщика. Это с самого начала было моё: я люблю глубоко разбираться в процессах и докапываться до деталей. Это, наверное, больше соответствует моей личности. 

Но я всё равно остаюсь рядом с разработкой. Делюсь наблюдениями, как размываются грани профессии. Ну и немного ностальгирую.

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

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

- альфа-тестирование с реальными пользователями;

- использование формата .aab вместо привычного .apk;

- автоматизация публикации через RuStore API.

Всем привет! Меня зовут Павел, я технический лидер тестирования в Альфа-Банке в направлении мобильной разработки.

Хотел бы поделиться способами отправки отчетов в один агрегированный запуск Allure TestOps из нескольких Jenkins джоб. В статье описано два способа, как это сделать. Сразу хочу отметить, что через стандартный плагин withAllureUpload это сделать не получится или не получилось у меня. Может есть какой-то секретный способ, как с ним работать и/или как настраивать. Но в интернете и в документации Allure TestOps такого решения не нашел.

Вот так учишь-учишь английский, думаешь, что ты все знаешь и на коне, а потом приходишь в IT-компанию после ВУЗа и осознаёшь, что, по сути, не знала ничего.

Какие открытия я сделала для себя в английском, когда начала делать первые шаги в technical writing и переводах 13 лет назад? Я тогда тщательно фиксировала всё интересное - и делюсь этим списком с вами. Кстати, он будет полезен не только тех. писателям, но и тестировщикам, аналитикам и вообще всем, кто пишет ТЗ, отчёты и test cases.

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

Soft skills стали тем, что помогло мне выйти на новый уровень. Я научился планировать, делегировать, вести переговоры, работать с командой. Всем привет! Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке и в этой статье я расскажу, какие soft skills действительно важны, как их развивать и почему без них сложно расти в IT.

Мы в hh очень любим UI-тесты, ими покрывается практически вся функциональность наших приложений, и даже backend-разработчики прогоняют тесты мобильных платформ перед развертыванием своих фич. Однако наши механизмы UI-тестирования разрабатывались более 8 лет назад и с тех пор почти не изменились.

Кто-то скажет, что старые решения прошли проверку временем и что «работает — не трогай»... Возможно, и так. Но сейчас мы внедряем новую дизайн-систему, а новые компоненты требуют адаптации всех тестов — не лучшее ли время для перемен?

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

Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь нулевого количества инцидентов в продакшене за отчётный период.

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

Я уверен, вы слышали про Robolectric, но использовали ли хоть раз для UI‑тестирования или screenshot-тестирования? Да, у библиотеки неоднозначная репутация в Android-комьюнити. Возможно, вы будете в восторге, когда её устройство перестанет быть для вас загадкой.

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

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

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

Ранее мы разбирались с основами Kafka (часть1), рассматривали, как тестировать микросервисы (часть2) и предугадывали ошибки offset explorer и kafka ui (часть 3). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером. 

Преимущества брокеров

Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API?

Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров: 

1. Асинхронное взаимодействие

API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает. 

2. Масштабируемость

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