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

Мы в Digital Security часто проводим анализ Android-приложений, поэтому пришло время поделиться некоторыми накопленными знаниями и сделать обзор по тому окружению, который мы используем каждый день.

Существует множество вариантов для настройки пентестерского окружения, которые можно выделить в две группы - виртуальные девайсы и физические.

У нас есть некоторое количество рутованных девайсов с одним и тем же окружением, однако иногда приходится использовать виртуальные устройства, в основном это Android Studio AVD.

Не так давно компания Microsoft зарелизила Windows Subsystem for Android (TM). Меня заинтересовал данный инструмент на столько, что я бросил своё рабочее окружение на Fedora Linux и поставил Windows 11.

Можно было бы писать эту статью в контексте реального устройства или виртуального девайста Android Studio, но мне кажется интереснее будет разобрать Windows Subsystem For Android 😄

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

Меня зовут Сергей, я занимаюсь нативной автоматизацией тестирования мобильных приложений (iOS) в компании РТЛабс. 

В данной статье я расскажу, как внедрялась отчётность на наших проектах, какие средства использовались и о порядке действий для получения результатов прогона автотестов в Allure.

Это первый текст на канале, так что сначала я хочу представиться: вряд ли кто-то всерьез будет прислушиваться к анониму, даже если он весь из себя экспертный эксперт. Итак, привет, я - Женя Шаповалов, Senior Android/Flutter Developer в компании Innowise (и хэд mobile department там же). В мобильной разработке я с 2015 года, начинал с Android, а за Flutter мы принялись вместе с коллегами в Innowise - да так мощно, что в итоге в компании появилось отдельное направление разработки.

Ну что, вроде бы заслуживаю доверия? Тогда погнали!

Сегодня рассказываю, как правильно тестировать код,  и делюсь личным опытом. Да-да, ты все понял верно: при разработке мобильных приложений тестирование проводит не только QA-инженер, но и сам автор кода. Причем не только в самом конце, когда приложение почти готово, но и в процессе. Мы сегодня рассмотрим оба этапа. 

Привет!

Я - Урманчеев Станислав, QA Automation Engineer на проекте «Лояльность» в Mир Plat.Form (НСПК). Хочу поделиться с читателями Хабра нашим опытом в создании и развитии фреймворка для автоматизации тестов на Appium.

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

Дисклеймер: о Kotlin dsl есть подробная статья на Хабре и документация на Kotlinlang.

Всем привет!

Приглашаем всех мобильных разработчиков и просто неравнодушных ребят на совместный митап Rambler&Co и Okko.

Выйдем на связь 8 сентября с 19:00 до 21:00 в уже привычном смешанном формате – в онлайне и офлайне.

Возвращаемся к нашему любимому вопросу - много теории, мало практики. Где тренироваться тестированию самоучке или человеку, которому не хватает практических заданий на курсах?

Представьте, что тестирование программного обеспечения можно упростить? Проводить его без многочисленных обсуждений, вопросов, баг-репортов и метрик?

Привет! Я Слава, QA в мобильной разработке СберЗдоровья, и я хочу рассказать о том, как менялись наши процессы тестирования за прошедший год, какие проблемы в связи с этим встречались, и как мы их решали.

Эта статья – большущий гайд по технологиям, которые мы в СДЭК используем для проверки наших внутренних приложений, написанных на React Native. Часть из этих подходов вполне можно применить не только в мобильной разработке, но и за её пределами. Дальше буду описывать все в контексте веб-разработки. Если вас это еще не испугало – приглашаю окунуться в головокружительный мир автотестирования мобильных приложений.

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

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

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

Мы в 2ГИС придумали собственное решение — и уже четыре года проводим инженерные литературные клубы. Расскажу, что это такое и что мы получаем в итоге.

Подсчитываем минимальное достаточное количество тест-кейсов для тестирования граничных значений и эквивалентных классов.

Привет! Меня зовут Денис Кудряшов, я инженер по тестированию в Waves Enterprise. В этом посте я расскажу о концепции PageObject, прокомментирую утверждения ее создателя Мартина Фаулера, а в конце расскажу, как мы в компании расширили PageObject и пришли к концепции Testing entity Definition Object (TDO).

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

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

Ранее мы рассказали, как и почему перешли от хаотичных релизов к еженедельному выпуску нашего приложения на iOS и Android. Ниже поделюсь, как при этом мы уменьшили время проверки релиза с 3-4 дней для одной из платформ до 4 часов на проверку сразу двух платформ.

Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. При создании списка проверок мы попросили помощи у команды информационной безопасности, отдельная благодарность Дмитрию Терёшину за проведённую встречу с подробным разбором всех кейсов. Его интересную статью по работе утилиты CheckKarlMarx можно увидеть здесь.

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

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

Тестирование — один из важнейших процессов в разработке. Однако без измерения его эффективности сложно сказать, насколько продуктивно и правильно работают тестировщики. Главный инженер-тестировщик Группы «Иннотех» Павел Петров поделился метриками, которые используются в рабочих проектах.

Когда вы запускаете новый продукт, обеспечение качества (QA) очень важно. Независимо от того, отдаете ли вы аутсорсинг команде QA или выполняете внутренние проверки, вам необходимо создать план тестирования. Это гарантирует, что в процессе обеспечения качества ничего не будет упущено.

Если вы новичок в планировании тестирования, эта статья ответит на все ваши вопросы и предоставит основу для планирования.