У каждого тестировщика рано или поздно наступает неловкий момент. Обнаружился вредный баг и его необходимо локализовать. По закону подлости баг воспроизводится нестабильно, при непонятных шагах и только на некоторых устройствах. Есть логи, но они не информативны. Разработчик занимается новой функциональностью, он не может отвлечься от текущих задач, пока не будут найдены четкие шаги воспроизведения. Менеджер ждет исправления (надо быстрее, заказчик переживает).
Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.
Конечно, можно перечитать всю доступную документацию для разработчиков, но вряд ли это время заложено в сроки проекта. Есть путь проще и продуктивнее: узнать у разработчика, что представляет из себя та функциональность, в которой возникает баг.
Те, кто тестирует мобильные приложения на различных устройствах не первый год, не понаслышке знают, что большая часть такого тестирования — это приведение устройства и приложения в нужное состояние: правильная геолокация или скорость перемещения, состояние сервера, наличие или отсутствие необходимых ресурсов. Времени на это уходит много, а в случае со сложными приложениями — непозволительно много.
Для ускорения этого процесса уже достаточно давно используется debug-консоль, которая позволяет быстро сформировать нужное состояние приложения и заниматься тестированием сразу. В своём докладе я расскажу об опыте использования таких панелей на популярных ОС: Android, iOS и Windows Phone, а также на паре непопулярных. Мы рассмотрим варианты решений для клиента и сервера, как защитить этот режим от попадания в руки пользователя и как убедить разработчиков в его необходимости. Ну, и пара фейлов, конечно же, куда без них.
Некоторое время назад мы рассказали вам об автоматическом тестировании нашей Почты на Android и получили огромное количество вопросов от читателей. Сегодня приоткроем вам часть нашей «внутренней кухни», которая касается автотестирования на iOS. Для тестирования каждой сборки мы проводим более 500 автотестов, которые выполняются менее чем за один час. Как мы их реализовывали и зачем? С какими проблемами сталкивались и как смогли их решить? Обо всём этом читайте под катом.
Схематически рабочий процесс выглядит следующим образом:
Нажмите на картинку, чтобы увеличить изображение
Схема показывает начальные, наиболее жесткие и критически важные шаги задачи на пути к релизу. Начнем с одного из первых компонентов — Code Review.
Широко известно, что iOS - достаточно закрытая система. Apple четко следует своему курсу на высокое качество приложений и ограничивает установку приложений из сторонних источников. И хотя для пользователей это может быть благом, в тестировании такая закрытость может очень сильно усложнять рабочий процесс. Ведь для того, чтобы установить приложение из среды разработки на реальное устройство, нужно обладать платным аккаунтом разработчика Apple.
По крайней мере, так было до недавнего времени. С выходом Xcode 8 Apple сняла это ограничение, и теперь можно подписывать приложения, даже не участвуя в этой программе. Однако этот факт до сих пор малоизвестен, к тому же нужно очень чётко следовать правилам, чтобы у вас получилось подписать приложение. В этом видео, которое является частью курса “Тестирование мобильных приложений”, рассматривается схема подписывания и установки приложения на iOS-устройство:
Мир не стоит на месте: еще десять лет назад пользователи выходили в интернет с помощью компьютера, а сегодня по статистике большая часть посещений приходится на мобильную версию сайта или мобильные приложения. Поэтому требования к стабильности и удобству использования этих приложений становятся выше.
В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.
На старте процесса по автоматизации в нашей команде было два человека на два проекта и по 100 тест-сценариев на каждую платформу и довольно сжатые сроки. Мы искали решение, на разворачивание и доработку которого у нас бы ушло минимум времени. И еще мы надеялись, что решение быстро освоят новые сотрудники.
Тестирование клиент-серверных мобильных приложений - пожалуй, одна из наиболее сложных задач в отрасли. К проблемам фрагментации девайсов и ОС добавляются проблемы со связью и возможные баги на самом сервере. В таких условиях нужно тестировать каждую из областей изолировано, чтобы проблемы с приложением не мешали и не замедляли проверку клиент-серверного протокола. Поэтому тестировщикам часто необходимо перехватывать запросы от приложения к серверу, а зачастую и подменять их. Для этого стоит научиться пользоваться инструментами перехвата трафика.
В качестве такого инструмента отлично подходит Charles Proxy Server, который создаёт на машине тестировщика прокси, через который можно пускать запросы, в том числе и от смартфона. Проще всего его использовать, конечно, с эмулятором, однако это возможно далеко не всегда. Поэтому мы сделали небольшой обучающий ролик, в котором показано, как настроить работу прокси с минимальными усилиями.
Этот ролик является частью курса "Тестирование мобильных приложений", следующая группа которого стартует уже через неделю. Если вас заинтересовал этот тренинг - можете почитать отзывы или записаться на участие. Больше роликов, посвящённых тестированию мобильных приложений, вы можете увидеть на канале в Youtube
Мобильные телефоны вошли в нашу жизнь повсеместно, и распоследний захудалый сервис имеет собстственное приложение. Да даже если не имеет – значит, у их сайта отзывчивый дизайн и его можно использовать при плохой связи, а не только на большом экране с оптоволоконным соединением. Как тестировщик сайтов или приложений на Андроид/Айфоне/ВинФоне, вы должны изобразить из себя реального пользователя – то есть иметь один или несколько смартфонов, как минимум тот, которым чаще всего пользуются ваши потребители. Не забываем и о ручном, и об автоматизированном тестировании. Вдруг у вас нет миллиарда евро, долларов или фунтов на покупку всех возможных смартфонов для тестирования? Будете ли вы полагаться на инструменты разработчика Chrome для браузера, зная, что разработчики и так "по-быстренькому" протестили с их помощью свою работу?
При тестировании Android-приложений можно часто столкнуться с проблемами, возникающими при переходе приложения из одного состояния в другое. Так, например, нередки утечки памяти при сворачивании и разворачивании приложения, или краши после ухода телефона в спящий режим.
Конечно, такие баги так или иначе находятся, даже если их не искать специально. Однако для обеспечения действительно высокого качества тестируемых приложений нужно чётко осознавать, почему подобные ошибки возникают, и как их искать. А для этого необходимо понимать, как происходит процесс изменения состояний в Android.
Android-программистам эта тема хорошо известна под названием Android Activity Lifecycle, или жизненный цикл операции. Конечно, тестировщикам, даже продвинутым, вовсе необязательно разбираться в данном вопросе полностью, однако базовое его понимание может сильно упростить жизнь и ускорить тестирование. Для того, чтобы показать, как это работает, мы записали небольшое видео.
Все, кто хоть раз сталкивался с тестированием мобильных приложений, знает, что оно имеет свои особенности и отличается от тестирования десктопных и веб-приложений.
На конференции QA Fest 2016 докладчики уделили немало внимания вопросу мобильного тестирования. Что лучше всего проверять в первую очередь, какие сценарии нельзя игнорировать, какой инструмент наиболее подходящий - эту и другую полезную информацию можно найти в записях докладов, опубликованных ниже:
Анна Карпенко - Специфика тестирования мобильных приложений
Татьяна Люлюченко - Немного о мобильных браузерах
Василий Сливка - 10 лучших практик для тестирования мобильных приложений
Денис Яременко - Как облегчить процесс мобильного тестирования
Мир мобильного тестирования очень специфичен: огромный зоопарк различных устройств, небольшие (по сравнению с десктопами) экраны, специфические виды передачи данных - всё это значительно усложняет работу с девайсами на уровне глубже обычного пользователя. Во время работы тестировщики мобильных приложений часто сталкиваются с рутинными, но нетипичными для других сфер тестирования задачами: как перекинуть логи на компьютер, залить тестовые данные на девайс, набрать ссылку для скачивания нового билда и так далее. Всё это на десктопе или ноутбуке занимает всего несколько секунд, а на мобильных устройствах - чуть ли не больше времени, чем собственно тестирование. Очевидно, что специалисту невыгодно тратить своё время на решение этих задач, однако сталкивается он с ними каждый день.
С ростом профессионализма в арсенале специалиста появляются различные вспомогательные инструменты, которые позволяют снизить потери времени на рутинные задачи почти до нуля. Однако ничего не мешает и начинающим тестировщикам использовать подобные инструменты, ведь они бесплатны, общедоступны и понятны каждому. В этом видео, которое является частью тренинга “Тестирование мобильных приложений: начальный уровень” (автор и ведущей тренинга Арсений Батыров), собраны 7 видов утилит, которые значительно облегчают жизнь мобильного тестировщика и отчасти даже ускоряют процесс самого тестирования:
Автор: Никита Анисимов
Оригинал статьи: