Компания
41,88
рейтинг
10 октября 2013 в 16:27

Разработка → Процесс тестирования мобильных приложений

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

Под катом я расскажу как мы тестируем мобильные приложения.




Тестирование требований


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

навигационная схема за три моря

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

Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.

В основном на этом этапе используется basecamp.

Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.



Например, для проекта Trava на этом этапе было написано 1856 тестов.

Первый шаг тестирования закончен. Проект уходит в разработку.

Билд-сервер


Все наши проекты собираются на TeamCity билд-сервере.



Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков. Красным отображаются билды выпущенные за последние сутки, их нужно тестировать активнее, чем белые.



Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.

Тестирование билдов бывает быстрое и полное.

Быстрое тестирование


Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.

Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.

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

Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.

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

Для андроид приложений запускаются monkey тесты.

adb shell monkey -p ru.stream.droid --throttle 50 --pct-syskeys 0 --pct-ap
pswitch 0 -v 5000

По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).

Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).

Критичность бага определяется по таблице.
таблица определение критичности ошибки

После завершения тестирования PM получает подробное письмо-отчет.
отчет о завершении тестирования

Полное тестирование


Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.

Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.

Очень важный шаг — тестирование обновлений. Почти все приложения хранят данные локально (даже если это кука логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся. Тестировщик скачивает билд из маркета, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет, что все на месте. Затем прогоняет smoke-тест. Процесс повторяется на 2-3 устройствах.

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

Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.

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


Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.

Тестирование внешних сервисов


Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.

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

Учет времени


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



UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика


Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
Автор: @junk
Touch Instinct
рейтинг 41,88
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Комментарии (22)

  • +2
    Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту.

    Прям всех всех? Обычно, заводят специальный регрешн тестран, который постепенно пополняется тест кейсами.
    • 0
      да, все из-за ограничений ситечка для проектов длительностью меньше полугода гоняются все чек-листы. Для длительных со временем собирается регрешн чек-лист
  • 0
    Сколько у вас живых Android устройств в зоопарке?
    • 0
      15

      Как у вас устроено тестирование?
  • 0
    А вы не в курсе случайно, как обстоят дела с Xamarin Test Cloud? Я давно подписан на бета-тест, но никаких новостей с тех пор не видел.
    • 0
      не в курсе, ходит слух, что пока все далеко от боевого использования.
  • 0
    Подскажите, какими сервисами бета-тестирования пользуетесь (Hockey, Crittercism, TestFairy, etc)?

    Чем отличается флоу для iOS и используете ли обезьянку AntEater для iOS?
    • 0
      никакими не пользуемся :) Для ios обезьянит Appthwack

      Флоу для iOS почти ничем не отличается, только билды ставим из testflight а не с билд-сервера
  • +3
    У нас количество тестироващиков на программиста зависит от проекта. Если для программиста это изменение одной строчки кода, а для тестировщика — регрешн всего приложения (1500 тест кейсов) руками, потому что автоматизации на этом прокте еще нет, а фикс важный и срочный, то может и 3-к-1 быть в пользу QA.
    А бывает и наоборот, с нуля строится приложение — два back-end программиста, два UI, специалист по базам данных, тех.лид и архитектор в одном лице, и всего один тестировщик (но, правда, очень хороший). Сейчас этому тестировщику дали автоматизаторов в помощь, поскольку какое-то стабильное количество функционала набралось и его решили автоматизировать. Ну что, прошло пару месяцев, дизайн решили изменить, вся автоматизация сломалась, и бедный тестировщик опять работает ночами, пока автоматизаторы фиксят скрипты.
  • 0
    Занимаюсь Android-разработкой.
    Во многих компаниях, с которыми я взаимодействовал, с тестированием Android-приложений все обстоит не очень хорошо — во-первых, фактически отсутствует автоматизированное тестирование, а во-вторых, никто даже не задумывается об этом. Ведь на самом деле автоматизированному тестированию поддаются очень многие вещи в мобильной разработке — конечно, нельзя говорить о том, что можно полностью отказаться от ручного тестирования, но ведь есть все возможности сократить его до минимума.
    Впрочем, вам большой респект — у вас действительно выстроена достаточно неплохая и удобная система.
    • 0
      мы для себя посчитали, что автоматизация не выгодна. Только на очень долгосрочных проектах с фиксированным UI. Хотя периодически обдумываем внедрение.
  • 0
    Кто-нибудь знает про инструменты для построения навигационных схем с макетами экранов? Или фотошоп в помощь?
    • +1
      мы в omnigraffle рисуем
  • 0
    Очень интересный пост, спасибо!

    Написал коллегам про appthwack.com, потому что раньше о таком не слышал. И сразу возник вопрос про NDA. Я нашел упоминание об этом appthwack.com/customeragreement в пункте: 11. CONFIDENTIAL INFORMATION
    На сколько я понял, они пишут, о том что прилагают все усилия для сохранения конфиденциальности информации имеющей коммерческую ценность, бла, бла, бла, что так же включает подписание их сотрудниками NDA. А вы таким вопросом задавались? Сталкивались со страхом заказчика передавать билд приложения кому-то другому или заказчики обычно не знают таких деталей? :)
    • +1
      заказчики не знаю таких деталей. Туда же можно и tesflight отнести, через который этот билд заказчик себе ставит. Вопрос конечно не однозначный, но проблем пока не было
      • 0
        можно отнести testflight, согласен, но тут риск больше, потому что они запускают сами приложение. Даже делают скриншот Launch image.
  • +1
    Могу рассказать про организацию тестирования в текущем проекте. Вообще это тема отдельной статьи, поэтому не буду особо вдаваться в причины выбора решений, можно в комментариях пояснить.
    Мы разрабатываем iOS приложение соц. сеть, причем сервера своего нет, используем Parse.com
    Были написаны интеграционные тесты с помощью SenTestingKit, которые тестируют некоторую бизнес логику приложения и код выполняющийся на сервере. Так же есть юнит тесты. Подняли сервер hudson-ci.org, который берет последний код с git, и запускает sh скрипты, которые запускают тесты. Для запуска тестов и красивого отображения логов используем xtool github.com/facebook/xctool
    Так же есть скрипт, который мержит(что может) production с development.
    Недавно подключился тестировщик для ручного тестирования.
  • +1
    Тоже работаю тестером на Андроиде в одной большой компании.
    Ручное тестирование на данный момент единственный вариант. Устройств на разных версиях ОС около 15 (не все используются сразу) — разработчикам тоже нужны аппараты, не только тестерам.
    Софт — TestLink, Eclipse для снятия и небольшого анализа логов.
    Сейчас изучаю тему автоматизиации. Столкнулся с тем, что документация Google пропускает важные шаги, что что начинающему автоматизатору просто не понятно, какой первый шаг надо сделать. Что-то работает не так, как написано в документации. В общем, Google в помощь, но именно как поисковик. Но уже хорошо разобрался, в Eclipse можно писать тексты для нашего приложения, даже не имея его исходного кода, не редактируя его. Правда, для этого требуется Андроид 4.1 и выше. В нем появился UIAutomator, кардинально упрощающий работу. Можно имитировать основные действия с устройством (нажатия на экран, свайпы), анализировать содержимое экрана и свойства элементов интерфейса.
    Впрочем, не все автоматизируется. Если надо проверить, как наше приложение обработает звонок с другого телефона, надо брать это второй телефон и звонить на тестовый. Как это обойти, пока не придумал. А ведь одна из самых сложных функций приложения, ее бы автоматизировать.
  • 0
    Да, просьба автору — сделайте, пожалуйста, картинки открываемыми в большем размере!

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

Самое читаемое Разработка