Тестирование — очень важный этап разработки мобильного приложения.
Цена ошибки при выпуске мобильного приложения высока.
Приложения появляются в Google Play в течение нескольких часов, а в Appstore — в течение нескольких недель.
Неизвестно, сколько времени потребуется пользователям для обновления.
Ошибки вызывают резкую негативную реакцию, пользователи оставляют низкие оценки и истеричные отзывы.
Новые пользователи, видя это, не устанавливают приложение.
Мобильное тестирование — сложный процесс: десятки разных разрешений экрана, аппаратные различия, несколько версий операционных систем, разные типы интернет-подключений, внезапные обрывы соединения.
Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на одного программиста), а за его разработкой и процессами следит выделенный тест-лид. Под катом я расскажу вам, как Мы тестирование мобильных приложений.
Тестирование требований
Тестирование начинается до разработки.Дизайнерский отдел передает тестировщикам схему навигации и макеты экранов, руководитель проекта — невидимые на дизайне требования.
Если дизайн предоставлен заказчиком, макеты проверяются нашими дизайнерами перед отправкой в отдел тестирования.
Тестировщик анализирует требования на полноту и несоответствие.
В каждом проекте первоначальные требования содержат противоречивую информацию.
Мы решаем их до начала разработки.
Также в каждом проекте требования неполные: не хватает макетов второстепенных экранов, ограничения на поля ввода, отображение ошибок, кнопки никуда не ведут. Неочевидные на макетах вещи не очевидны: анимация, кеширование картинок и содержимого экрана, работа в нестандартных ситуациях.
Недостатки требований обсуждаются с руководителем проекта, разработчиками и проектировщиками.
После 2-3 итераций вся команда гораздо лучше понимает проект, запоминает забытый функционал и фиксирует решения по спорным вопросам.
На этом этапе в основном используется Basecamp. Когда требования полны и согласованы, тестер создает дымовые и функциональные тесты, охватывающие исходные данные.
Тесты делятся на общие и специфические для разных платформ.
Для хранения и запуска тестов мы используем Ситечко .
Например, для проекта Трава На этом этапе было написано 1856 тестов.
Первый этап тестирования завершен.
Проект находится в разработке.
Сборка сервера
Все наши проекты собираюсь TeamCity построить сервер.
Если руководитель проекта поставит галочку «на тестирование», тестировщики получат письмо о новой сборке для тестирования.
Его номер отображается на мониторе в кабинете тестировщиков.
Сборки, выпущенные за последние 24 часа, отображаются красным цветом; их нужно тестировать активнее, чем белых.
Без «волшебного монитора» (кстати, на Android он работает) часто тестировались старые сборки.
И заказчик получил новый билд с ошибками.
Теперь, прежде чем запускать тестовые примеры, просто посмотрите на монитор, путаница решена.
Тестирование сборок может быть быстрым и полным.
Быстрое тестирование
Быстрое тестирование проводится после завершения итерации разработки, если сборка не выходит в релиз.Сначала проводятся дымовые тесты, чтобы понять, есть ли смысл тестировать сборку.
Затем все выполненные задачи и исправленные ошибки берутся за итерацию из Jira и результат тщательно проверяется на соответствие описанию задачи.
Если в задание включены новые элементы интерфейса, оно отправляется дизайнерам для сравнения с макетами.
Неправильно выполненные задания открываются повторно.
Ошибки сохраняются в Jira. При ошибках, не связанных с пользовательским интерфейсом, необходимо приложить логи со смартфона.
При ошибках пользовательского интерфейса — скриншоты с примечаниями о том, что не так.
После этого выполняются функциональные тесты для этой итерации.
Если обнаружены ошибки, не охваченные тест-кейсами, создается новый тест-кейс.
Для Android запускаются приложения тесты на обезьянах .
adb shell monkey -p ru.stream.droid --throttle 50 --pct-syskeys 0 --pct-ap
pswitch 0 -v 5000
По окончании тестирования в билд-сервере ставится галочка «тестирование пройдено» (да, название галочки не очень правильное :).
Если в ходе тестирования не обнаружено блокировщика, критических или серьезных ошибок, ставится галочка «можно показать заказчику».
Ни одна сборка не отправляется заказчику без одобрения отдела тестирования.
(По согласованию с заказчиком иногда присылаются сборки с серьезными ошибками).
Критичность ошибки определяется с помощью таблицы.
После завершения тестирования руководитель проекта получает письмо с подробным отчетом.
Полное тестирование
Перед выпуском проводится полное тестирование.Включает быстрое тестирование, регрессионное тестирование, тестирование на обезьянах на 100 устройствах и тестирование обновлений.
Регрессионное тестирование включает в себя выполнение ВСЕХ тестовых случаев для проекта.
Тест-кейсы не только для последней итерации, но и для всех предыдущих и общих тест-кейсов согласно требованиям.
Это занимает день или три на одно устройство, в зависимости от проекта.
Очень важный этап — тестирование обновлений.
Почти все приложения хранят данные локально (даже если это файл cookie для входа в систему), и важно убедиться, что после обновления приложения все пользовательские данные сохраняются.
Тестер скачивает сборку из маркета, создает сохраненные данные (логин, плейлисты, операции финансового учета), обновляет приложение до тестовой сборки и проверяет, что все на месте.
Затем он запускает дымовой тест. Процесс повторяется на 2-3 устройствах.
Разработчики часто забывают о переносе данных из старых версий, а тестирование обновлений позволило выявить множество критических ошибок со сбоями и удалением пользовательских данных о покупках.
Это спасло не одно приложение от гневных отзывов и потери аудитории.
Проводим релиз-монки-тест на 10 iOS и 80 Android устройствах с помощью сервиса.
По окончании полного тестирования, помимо написания, вручную составляется подробный отчет. 
Сборка выпускается только в том случае, если все тестовые случаи пройдены на 100%.
Тестирование внешних сервисов
Тестировать интеграцию с Google Analytics, Flurry или системой статистики клиентов непросто.Бывало, что сборки с неработающим Google Analytics выходили в релиз и на это никто не обращал внимания.
Поэтому обязательно необходимо создать тестовую учетную запись для внешних сервисов и проверить ее при полном тестировании.
Кроме того, статистика отправки фиксируется в журналах, которые проверяются тестировщиками.
После релиза тестовый аккаунт заменяется живым.
Учет времени
Время тестировщиков отслеживается в отдельном проекте Jira. Для составления тест-кейсов, запуска тестов и написания отчетов по проекту создается отдельная задача, в которой стандартными средствами фиксируется затраченное время.
UPD: расскажите, как у вас работает тестирование, хотя бы сколько тестировщиков на одного разработчика
Подпишитесь на нашу хабра блог .
Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
Теги: #тестирование #сайтечко #Jira #сборка сервера #тестовый полет #appthwack #тестирование ИТ-систем #Разработка мобильных приложений
-
Инсайдерская Информация Об Игровом Процессе
19 Dec, 24 -
Nokia Dvlup Приходит На Хабрахабр
19 Dec, 24
