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

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

    Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в 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: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика


    Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
    Метки:
    Touch Instinct 126,33
    Разрабатываем мобильные приложения
    Поделиться публикацией
    Похожие публикации
    Комментарии 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
                          Да, просьба автору — сделайте, пожалуйста, картинки открываемыми в большем размере!

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

                        Самое читаемое