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

Тестирование мобильных приложений — дело нелёгкое. Всякий раз, когда я разговариваю с разработчиком, всегда оказывается, что тестирование — это одновременно волнующий и мучительный этап разработки. Волнующий потому, что продукт наконец-то близок к долгожданному состоянию полной готовности, а мучительный... ну, если вы хоть раз пробовали откапывать неизвестные ошибки в софте, вы меня понимаете. Чтобы провести тестирование правильно, необходим многоуровневый подход, который требует временных затрат, ресурсов и терпения. Есть несколько способов тестирования приложений, но не каждый из них подходит любому разработчику.

Многоуровневое тестирование

Мы попросили Ли Уильямсона, ведущего программиста IBM и члена CTO Team, рассказать нам о различных подходах, которые используют разработчики при тестировании приложений. Далеко не всегда тестирование приложения сводится к вылавливанию ошибок в исходном коде. Мобильные приложения — это зачастую узконаправленные программные системы с большим количеством взаимодействий между фронтендом, логикой и облачным бекендом. Таким образом, ваш код может безупречно работать на устройстве, но его работа будет подорвана ошибками, которые поступают из облака. Или проблема может быть в логике приложения — сторонних библиотеках, SDK, или сервисах. Так что иногда, если что-то не работает, найти ошибку легко, но чаще всего у вас даже идеи нет, в чем проблема.

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

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

В идеале тестирование вручную является одним из завершающих этапов жизненного цикла разработки приложения. Все сделано и почти готово к поступлению в продажу. Этот этап может быть менее болезненным, если, например, воспользоваться услугами стартапов, таких как Crashlytics (Бостон) — они предоставят вам SDK, который с точностью до строчки в коде определит, почему приложение падает, и предоставит данные о его состоянии на момент сбоя.

Действительно ли облако мешает работе вашей системы?

Как только разработчики переходят на облака в качестве бекенда, появляется новый уровень, требующий проверки. По мнению сотрудников IBM, такая проверка — их сильная сторона в области тестирования. Они могут изолировать или симулировать уровень логики и облачный бекенд, чтобы ещё до фактической интеграции между устройствами, серверами и облаком дать разработчикам представление о том, как будет работать приложение. Это осуществляется при помощи Green Hat — тестовой платформы IBM для различных облачных сервисов. Мобильные облачные сервисы, работающие по схеме бекенд-как-сервис, например Kinvey, дают разработчикам экземпляр структуры своего облака (которое работает через Rackspace, Azure или Amazon). Он позволяет конкретному компьютеру выполнять функции мобильного устройства.

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

Другой вид облака

Недавно один разработчик жаловался мне на тестирование приложений, и его сетования заключались вот в чем: «Есть слишком много мобильных устройств, на которых установлено до черта версий операционных систем, установленных на различных смартфонах от различных производителей. Протестировать всё это просто невозможно». Это была суть его жалоб. Только слова, которые он использовал были ...поострее.

А ведь он прав. На мировом рынке продается более 300 различных типов смартфонов на базе Android. Количество телефонов на базе Windows также растет, не говоря о разработчиках, которым нужно, чтобы приложения или сайты запускались на BREW, Symbian и Bada девайсах. Даже тестирование приложений для iPhone усложнилось из-за наличия на рынке трёх версий устройства (3GS, 4, 4S), которые использует большинство покупателей. При этом существуют также различные версии iOS (не все знают как их обновлять, а некоторых это просто не заботит), работающие на различных носителях. iOS не фрагментирована, как Android, но всё-таки есть ещё фрагменты, которые должны быть протестированы в самой системе.

Чтобы протестировать работу приложений на различных устройствах, разработчик может приобрести все эти смартфоны и планшеты, связать с сервером и зависать над спецификацией каждого устройства. Это непрактично, трудоемко и дорого. Есть несколько сторонних сервисов, которые могут предоставить разработчикам «облако устройств» для тестирования приложений одновременно на многих устройствах. IBM использует Perfecto Mobile и Device Anywhere для своих облаков девайсов, но есть также другие решения от таких компаний, как Apkudo.

«Это тоже часть нашей стратегии — принятие во внимание того, что существует много различных методов мобильного тестирования, и что некоторые из этих методов применимы для мобильных приложений, но по каким-то другим причинам клиент может посчитать тот или иной метод неприемлемым,» — говорит Уильямсон.

Выбор ... а он вообще есть?

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

В работе с IBM есть ощутимые преимущества. Например, не так много других компаний предлагают услуги по системному тестированию. Если у компании нет готового решения, она может либо приобрести его у другой компании (GreenHat), либо работать совместно с компанией, которая им обладает (Device Anywhere). Сам же Уильямсон согласен с тем, что системное тестирование может быть проведено и без прибегания к услугам IBM, но это может не оправдать затраченных усилий.

«Конечно, есть и другие пути разработки качественного комплексного решения по тестированию, но в таком случае клиент сам должен будет заниматься интеграцией, то есть, по сути, быть самому себе системным интегратором, в то время как в IBM мы делаем это на профессиональном уровне,» — говорит Уильямсон.

Оригинал: http://www.readwriteweb.com/mobile/2012/03/squashing-bugs-the-many-layere.php

Для тех, кто изучает английский язык, предлагаем лексический разбор статьи в блоге Nimax»: http://blog.nimax.ru/blog/post?id=338.

Анатолий Ларин
Менеджер по развитию бизнеса в Touch Instinct

В свое время я проводил исследование инструментов автоматизированного тестирования мобильных приложений (http://habrahabr.ru/post/123026/) и в корне не согласен со статьей.

Автоматизация тестирования приложений, в смысле не unit-тестов, а тестирования приложения целиком, сейчас вполне возможна (UIAutomation, Robotium), но в подавляющем большинстве случаев не рентабельна. Для автоматизации вам потребуются тестировщики гораздо более высокой квалификации и больше времени, фактически автоматизация это написание еще одной программы. Это оправданно для длительных проектов с большим количеством итераций и небольшими интерфейсными изменениями. Думаю, такие проекты есть только у Яндекса или другой большой компании. Мы все тестируем вручную, при этом проверяется не только наличие ошибок, но и отзывчивость и удобство приложения.

Облака устройств Perfecto Mobile и Device Anywhere, на мой взгляд так же не помогут вам в тестировании. Когда я их тестировал полгода назад, работа со смартфонами ужасно тормозила и не передавала реальных ощущений работы с приложением, с которыми столкнутся ваши пользователи. В таких условиях тестировщики не смогут нормально работать. Так что закупка всевозможных устройств — верный путь, которому следуют все известные мне российские разработчики приложений.
 

Николай Демьянков
Руководитель департамента мобильных решений в AREALIDEA

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

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

Описанное в статье решение от IBM по тестированию в «облаке девайсов» является, на самом деле, очень заманчивым. Если оно действительно позволяет покрыть большой объём устройств и различных ОС для тестирования — это может спасти проект от множества проблем и сделать его более качественным. Однако за удовольствие надо платить, и цена за такое тестирование может быть высока. Если да, то данный сервис, имеет смысл использовать только крупным компаниям, которые готовят к выпуску какой-либо серьёзный продукт, и хотят проверить его как можно детальнее.

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

1. Покрытие Unit-тестами исходного кода приложения для отлавливания потенциальных багов в работе приложения.
    
2. Создание автоматизированных тестов для проверки UI приложения с моделированием различных возможных сценариев поведения пользователя (для сайтов — это Selenium, для Android ОС — специальная библиотека Robotium).
    
3. Ручное тестирование на виртуальной машине, которая обычно идёт вместе с соответствующей SDK, и позволяет проверить приложение на разных версиях ОС и на разных разрешениях экрана.
    
4. Ручное тестирование на реальных устройствах.

Помимо этого, при «падении» приложения на устройстве, некоторые ОС (тот же Android) предлагает пользователю отправить отчёт о произошедшей ошибке. Данный отчёт будет доступен разработчикам в соответствующей консоле и позволит увидеть проблемное место. При желании, можно встроить свою систему формирования отчёта об ошибке с последующей отправкой на сервер разработчика для обработки (естественно, с предварительного согласия пользователя).

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

Иван Козлов
Генеральный директор в CleverPumpkin

Количество сервисов, так или иначе связанных с мобильными приложениями, стремительно увеличивается. Часть из них, безусловно, посвящена теме тестирования, а именно упрощения этого процесса в контексте мобильных приложений. Помимо сервисов, описанных в статье, есть и другие интересные проекты, так или иначе связанные с тестированием. Например, TestFlight, HockeyApp, Fixber. Все они призваны помочь разработчикам выпустить качественный продукт, что, на мой взгляд, является крайне позитивным моментом.