Как тестировать мобильные приложения
Вы, как создатель своего продукта или услуги, понимаете как он работает, какие связи между процессами и чего хотят клиенты. Поэтому при тестировании хорошо определяете ошибки и недочеты.
Конечно, ваши возможности ограничены — как знаниями и навыками, так и техническим оснащением. Вы не сможете проверить работу приложения на разных устройствах или его безопасность, наличие ошибки в коде. Но вам подвластно проверить, как работает функционал и какие упущения во внешнем виде, удобство приложения.
Сценарии тестирования
Ваша задача — встать на место пользователя и пройти его путь от входа в приложение до закрытия, при этом выполнить все действия, которые ему доступны. В ходе прохождения выявить проблемы, с которыми пользователь не должен сталкиваться, или найти изъяны в дизайне, которые водят его в заблуждение. В профессиональной среде такие сценарии называются «функциональное тестирование» и «тестирование удобства пользования». Для каждого мы написали принципы и основные моменты, на которые нужно обратить внимание.
Функциональное тестирование
Обязательно нужно тестировать приложение на пограничных состояниях.Мы разработали веб-приложение для сервиса грузоперевозок Shustrikoff. Стоимость доставки зависит от удаленности от центра города, поэтому при тестировании проверяли адреса на границе Казани и другого района. Также можно проверить заявки в разных районах города, заказ назначенный на границе дневного и ночного тарифа и т.п.
Тестирование удобства пользования
- Как обозначены обязательные и необязательные поля для заполнения? Можно ли их отличить друг от друга?
- Понятно ли, как действовать дальше и куда нажимать? Если вы всматриваетесь в экран в поисках следующего шага или кнопки, зафиксируйте этот момент. Интерфейс должен быть интуитивно понятен, вести пользователя по конкретному маршруту в назначенную точку. Важную роль в этом играют как расположение элементов на экране, так и их стиль.
- Можно ли продолжить работу в приложении после того как свернул и обратно развернул его? Не выкидывает ли пользователя?
- Цвет кнопок с одинаковой функцией совпадает.
- Как воспринимается текст на экране: заголовок заметнее всех, шрифт не напрягает, текст читается легко, смысл понятен, поля учтены.
- Звук в приложении: что с ним происходит и как он звучит в разных состояниях приложения. Например, как работает приложение, когда подключена гарнитура или включается сторонний проигрыватель либо при сворачивании приложения.
- Сколько времени и шагов понадобилось для завершения основных задач приложения? Можно ли упростить этот путь?
Оформляем и передаем информацию разработчикам
Включаем режим «бюрократии», потому что правильно оформленная ошибка сэкономит вам и разработчикам часы работы.
Представьте: разработчики не будут уточнять детали каждой ошибки, переспрашивать, для разъяснений не понадобятся эти звонки по телефону, которые мало кто любит (Привет миллениалам!). В ваших отношениях с командой будет процветать гармония и полное взаимопонимание.
- Дайте название ошибке. Будет легче ориентироваться по списку и в разговоре с командой.
- Опишите ошибку. Что конкретно не так? Как задумывалось и должно быть?
- Приложите скриншот или запись экрана, если ошибка происходит при конкретной последовательности действий.
- Какая версия: десктоп или мобильная?
- Какая платформа: iOS или Android?
- Какой браузер и какая версия браузера?
- Дайте подробный путь к странице/экрану с ошибкой.
Скорее всего команда уже использует определенный сервис для работы с задачами, где и собирает всю информацию по приложению. Поэтому они могут дать внешний доступ, чтобы вы в этом же пространстве вносили информацию по результатам своего тестирования. Собирайте все в единой структуре в одном месте.
Тестирование – очень важный этап разработки мобильных приложений.
Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.
Мобильное тестирование сложный процесс: десятки различных разрешений экрана, аппаратные отличия, несколько версий операционных систем, разные типы подключения к интернету, внезапные обрывы связи.
Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.
Под катом я расскажу как мы тестируем мобильные приложения.
Тестирование требований
Тестирование начинается до разработки. Отдел дизайна передает тестировщикам навигационную схему и макеты экранов, менеджер проекта – требования невидимые на дизайне. Если дизайн предоставляет заказчик, макеты до передачи в отдел тестирования проверяются нашими дизайнерами.
Тестировщик анализирует требования на полноту и противоречивость. В каждом проекте исходные требования содержат противоречивую информацию. Мы их решаем еще до начала разработки. Так же в каждом проекте требования неполны: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок, кнопки никуда не ведут. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях.
Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.
В основном на этом этапе используется basecamp.
Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.
Например, для проекта Trava на этом этапе было написано 1856 тестов.
Первый шаг тестирования закончен. Проект уходит в разработку.
Билд-сервер
Все наши проекты собираются на TeamCity билд-сервере.
Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков. Красным отображаются билды выпущенные за последние сутки, их нужно тестировать активнее, чем белые.
Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.
Тестирование билдов бывает быстрое и полное.
Быстрое тестирование
Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.
Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.
Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.
Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.
После этого выполняются функциональные тесты этой итерации. Если были найдены баги не покрытые тест-кейсами, создается новый тест-кейс.
Для андроид приложений запускаются monkey тесты.
По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).
Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).
Критичность бага определяется по таблице.
После завершения тестирования PM получает подробное письмо-отчет.
Полное тестирование
Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.
Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.
Очень важный шаг — тестирование обновлений. Почти все приложения хранят данные локально (даже если это кука логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся. Тестировщик скачивает билд из маркета, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет, что все на месте. Затем прогоняет smoke-тест. Процесс повторяется на 2-3 устройствах.
Разработчики часто забывают о миграции данных со старых версий и тестирование обновлений позволило нам выявить множество критических ошибок с падениями, удалением пользовательских данных о покупках. Это спасло не одно приложение от гневных отзывов и потери аудитории.
Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.
В конце полного тестирования, кроме письма, вручную составляется подробный отчет.
Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.
Тестирование внешних сервисов
Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.
Поэтому в обязательно порядке для внешних сервисов создается тестовый аккаунт и он проверяется при полном тестировании. Кроме того отправка статистики фиксируется в логах, которые проверяются тестировщиками. При релизе тестовый аккаунт подменяется боевым.
Учет времени
Учет времени тестировщиков производится в отдельном Jira проекте. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время.
UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика
Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
По разным данным в среднем человек проводит с мобильным устройством от 3 до 6 часов в день. Это большая аудитория, возможно она даже больше аудитории десктопных приложений. Раз мобилками пользуется так много людей, значит там много денег. Чтобы заработать больше деньег качество приложения должно быть на высоте. Конечно же за это качество отвечают в большей степени тестровщики.
Чтобы обеспечить достойное качество мобильного приложения нужно знать основные принципы мобильного тестирования. О них и поговорим ( если что-то забыл, добавляй в комментариях ).
В конце статьи бонусом собрал видео лекции об особенностях мобильного тестирования.
С чего начать
Мобильные приложения делятся на 3 типа:
- Нативное приложение - приложение под определенную платформу доступное через маркетплейс (Google Play, AppStore и т.д.). Еще одно важно отличие - автономная работа в режиме оффлайн. Яркий пример мобильные игры.
- Веб-приложение - открывается через браузер, а значит это просто веб-сайт.
- Гибридное приложение - устанавливается через маркетплейс, а отображается внутри приложения как веб-сайт. Часто это приложения супермаркетов, недорогих доставок еды.
Немного о плюсах и минусах типов
Говорим о плюсах и минусах именно для тестирования. Если говорить в общем, то список будет намного длинее. Например, нативное приложение очень дорогое в ращработке и тестировании, что является минусом для бизнеса.
Плюсы нативного приложения:
- практически вся функциональность доступна в оффлайне
- скорость работы выше других типов моб. приложений
- полный доступ к функциям девайса (FaceID, отпечаток пальца, камера и т.п.)
Минусы нативного приложения:
- правки багов доезжают только при релизе следующей версии
- тестирование на каждой платформе
- занимают больше памяти
- правки багов приезжают быстрее
- тестирование проводится в браузере и не сильно завязано на ОС/модель телефона/платформу
- не требуется тестировать установку, удаление и обновление
- ограниченный доступ к функциональности девайса (FaceID, отпечаток пальца, камера и т.п.)
- не работают в оффлайне
Плюсы гибридного приложения:
- мультиплатформенные, т.е. реализация на всех ОС одна
- правки багов приезжаюь быстрее, т.к. по сути функционал это встроенный веб-сайт в приложение
- могут использовать большинство функций девайса
Минусы гибридного приложения:
- не работают в офлайне
- ограниченный доступ к функциональности девайса
Типы тестирования мобильных приложений
- Функциональное тестирование - проверка реализованного функционала. Чаще всего сравнивается реализация и ТЗ.
- Тестирование пользовательского взаимодействия (также известное, как тестирование удобства использования, тестирование UX) - удобства работы с приложнием: свайпы, тапы, скролы и т.п.
- Тестирование совместимости - установка на разные ОС, платформах, на разных моделях, проверка на разных разрешениях и т.п.
- Тестирование подключения - проверка на разных типах подключения(wi-fi, мобильная сеть), переключение типов и оффлайн работа
- Тестирование производительности - утечка памяти, стабильность работы при большом количестве пользователей и т.п.
Как выбрать устройства для тестирования
Платформа (смартфон или планшет), ОС определяютя техническим заданием.
Выбор версий и моделей базируется на статистике. Это либо внутреняя статистика вашего сервиса (google analytics, яндекс метрика) или общедоступные дашборды:
- официальная статистика использования устройств Apple
- официальная статистика использования устройств Android
- deviceAtlas - позволят получить выборку по разным параметрам (регион, производитель и т.д.)
- statcounter - аналог deviceAtlas
Дальше зависит от технической базы твоей компании. По возможностям выбираете тестирование на физических устройствах, сервисах удаленного доступа к физическим устройствам ( perfecto , Device Everwhere ) или на симуляторах/эмуляторах.
Не стоит забывать про тестирование на пользователях в бете. Это возможно тестирования на широком наборе устройств, с разными ОС, ресурсами и т.д. Например, в Google Play при публикации приложения есть возможность раздать новое приложение только на некоторый процент пользователей.
Основные проверки по типам тестирования
Функциональное тестирование
- Установка приложения
- Тестирование по ТЗ
- Соответствие общепринятым правилам, например, математическим
- Первый запуск приложения
- Открытие приложения из списках активных (горячий старт)
- Открытие приложения, когда его нет в списке активных (холодный старт)
- Открытие приложения интентом, т.е. вызвать другим приложением, например, тап по ссылке в мессенджере вызывает тестируемое приложение
- Закрытие (только тестируемого приложения, всех приложений в менеджере приложений)
- Удаление приложения из разных точек (логнтапом по иконке, из списка установленных приложений)
- Обновление ( важно проверить сохраность пользовательских действий)
Тестирование пользовательского взаимодействия
Про тестирование пользовательского взаимодействия можно говорить много, поэтому поговорим об этом в отдельном посте (не забудь подписаться , чтобы не пропустить).
Тестирование совместимости
- Проверка на платформах: смартфон, планшет. Возможно по ТЗ будет необходимость проверить на умных колонках, часах или навигаторе.
- Тестирование на разных девайсах: модель, производитель, версиях ОС.
- Если это веб-приложение, то проверить на топовых браузерах
- Проверка на разных разрешениях и масштабах, в альбомной и портретных ориентациях экрана
- Перенос приложения на внешний/внутрений носитель
- Проверка доступности 3rd party services (CDN, библиотеки и т.п.)
Тестирование подключения
- Тестирование при подключеном Wi-Fi, 4G/3G/E/etc
- Разрыв и восстановление сети
- Переключение с одного типа сети к другому
- Оффлайн
- Смена, отключение геопозиции
Тестирование производительности
- Если это веб-приложение, то замерить производительность Lighthouse , Яндекс Метрикой и т.п.
- Репорты с маркетплейсов. Например Google Play присылает отчет об опубликованном приложении (безопасность, краши и т.п.)
- Отзывы пользователей
- Нагрузочное/стресс/стабильности тестирование
Особенности, о которых нужно помнить
Некоторые особенности, которые отличают мобильные приложения от десктопных, и как следствие накладывают дополнительные условия тестирования:
- Смена геопозиции в широком диапазоне. Юзер мобильных приложений более подвижные, чем десктопные :)
- Устройства сильно различаются: платформа, ОС, разрешение, ориентация, ресурсы (память, камера, наличие внешней памяти, датчики освещенности, ориентация экрана, датчики bluetooth/NFC/Wi-Fi/4G/etc)
- Способ взаимодействия в 90% тач. Плюс многие сенсоры оснащены мультитачом.
- Отдельно стоит проверить установку/обновление/работы при недостатке памяти
- Работу при отключении/включении функциональности девайса: bluetooth, NFC, режим полета, ночное освещение, движение глазами и т.п.
- Ограничения ОС. Тут куча кейсов с блокировкой кук, передачи геопозиции и т.п. на уровне ОС.
- Извлечение/переключение sim/flash-карты
Бонус
Особенности тестирования мобильных приложений
Ваш пошаговый алгоритм тестирования мобильных приложений
Обеспечение качества (QA, от английского - Quality Assurance) является неотъемлемой частью жизненного цикла разработки любых приложений, включая мобильные. К сожалению, многие упускают из виду критические особенности тестирования мобильных приложений, которые часто приводят к сбоям, ошибкам в работе приложения и плохому качеству обслуживания клиентов.
Чтобы обеспечить успешную разработку любого приложения, специалист-тестировщик должен принимать участие во всех этапах разработки - от создания концепции и анализа требований, до создания спецификаций тестирования и выпуска готового продукта. Обеспечение качества также является ключевым элементом в последующих, после прохождения этапов разработки, обзорах программного продукта.
Однако часто бывает сложно определить, с чего начать организацию процесса тестирования мобильного приложения. Для беспроблемного тестирования мы рекомендуем просто выполнить девять указанных ниже шагов.
Давайте рассмотрим особенности тестирования мобильных приложений.
Цикл жизни спринтов
Этап 1: Планирование
Когда этап разработки приложения почти завершен, вы должны снова поставить перед собой вопрос - чего вы пытаетесь достичь разработкой данного приложения и какие у вас есть ограничения.
- Взаимодействует ли ваше приложение с другими приложениями?
- Насколько функциональны все возможности приложения?
- Является ли тестируемое мобильное приложение нативным, Mobile-web или гибридным?
- Ограничена ли задача тестирования приложения тестированием только внешнего интерфейса?
- Стоят ли задачи на тестирование бэкенда?
- Какова должна быть совместимость с различными беспроводными сетями?
- Как сильно данные приложения и свободное пространство, занимаемое им, зависят от особенностей использования приложения?
- Насколько быстро загружается ваше приложение, насколько быстро происходит серфинг по меню приложения и его функциям?
- Как будет обрабатываться возможное увеличение нагрузки на приложение?
- Влияют ли различные изменения в статусе и состоянии телефона на работу мобильного приложения?
Убедитесь, что вы договорились с командой тестировщиков о роли каждого из них и о ваших ожиданиях от процесса тестирования. В конце концов, общение является ключом к поддержанию правильной рабочей среды в команде.
Правильное понимание ролей и задач также относится и к моменту прописывания списка тест кейсов. Вся команда QA должна поддерживать и обновлять этот документ с отчетами по тестированию всех функций, реализованных на протяжении всего процесса разработки.
Этап 2. Определение необходимых типов тестирования мобильных приложений
Перед тестированием любых мобильных приложений определите, что именно в данном мобильном приложении вы хотите протестировать: набор функциональности, удобство использования, совместимость, производительность, безопасность и т. д. На этом же этапе имеет смысл выбрать методы тестирования мобильного приложения.
Тема связана со специальностями:
Определите, на какие целевые устройства направлено данное приложение, и какие требования к функционалу следует проверить.
Вы также должны определить, какие целевые устройства нужно включить в список тестирования.
Вы можете сделать это следующим образом:
• Выяснить, какие устройства будет поддерживать приложение;
• Определить, какая версия операционной системы будет самой ранней из тех, что поддерживаются приложением;
• Выявить наиболее популярные модели мобильных устройств у целевой аудитории;
• Определить набор не основных (дополнительных) устройств с экранами разных размеров, потенциально поддерживаемых приложением;
• Решить, будете ли вы использовать для тестирования физические устройства или их эмуляторы.
Этап 3: Тестовые случаи и разработка сценариев тестирования приложения
Подготовьте документ, описывающий тестовые случаи (test cases) для каждой тестируемой функции и функциональности.
В дополнение к функциональным тестовым случаям, также должны быть охвачены некоторые отдельные моменты (кейсы):
• Особенность использование батареи;
• Скорость работы приложения;
• Требования к данным;
• Объем используемой памяти.
Также перед началом тестирования важно определиться, какое сочетание ручного и автоматического тестирования вы будете применять.
При необходимости подготовьте отдельные наборы ручных тестовых случаев и сценариев для автоматического тестирования и адаптируйте их согласно требованиям проекта.
Этап 4: Ручное и автоматическое тестирование
Теперь пришло время для выполнения ручных и автоматизированных тестов.
Ранее, на предыдущих этапах, вы уже определили, какие тесты и скрипты использовать и подготовили их. Теперь, на текущем этапе, вы выполняете запуск тестов для проверки механизмов основной функциональности, чтобы убедиться в отсутствии поломок.
Автоматизированное тестирование мобильных приложений хорошо экономит время и другие ресурсы тестировщиков.
Этап 5: Тестирование юзабилити и бета-тестирование
После того, как базовый функционал протестирован, настало время убедиться, что мобильное приложение является достаточно простым в использовании и обеспечивает удовлетворительный пользовательский опыт. На этом этапе необходимо поддерживать соответствие матрице кроссплатформенности, чтобы обеспечить охват пользователей различных платформ, достигнутый бета-тестерами.
Пример матрицы поддержки разных версий платформы iOs
После того, как приложение будет протестировано внутри компании, вы сможете выпустить бета-версию приложения на рынок.
Тестирование совместимости
Мобильные устройства различаются в зависимости от платформы, модели и версии их операционной системы. Важно выбрать такое подмножество устройств, которое будет соответствовать вашему приложению.
Тестирование пользовательского интерфейса
Пользовательский опыт является ключевым элементом, при тестировании приложения. Ведь наше приложение разрабатывается именно для конечных пользователей. Вам следует качественно проверить удобство использования приложения, навигацию по его элементам и контент. Тестируйте меню, опции, кнопки, закладки, историю, настройки и навигацию приложения.
Тестирование интерфейса
Тестирование пунктов меню, кнопок, закладок, истории, настроек и навигации по приложению.
Тестирование внешних факторов
Приложения для мобильных устройств не будут единственными приложениями на устройстве пользователя. Вместе с вашим приложением будут установлены приложения от сторонних разработчиков. Возможно десятки таких приложений. Следовательно, вашему приложению придётся взаимодействовать с этими сторонними приложениями и прерывать работу различных функций устройства, таких как различные типы сетевых подключений, обращение к SD-карте, телефонные звонки и другие функции устройства.
Тестирование доступности
Мобильными устройствами могут пользоваться различные люди с ограниченными возможностями. По этой причине важно протестировать возможность работы с приложением людей с дальтонизмом, нарушениями слуха, проблемами пожилого возраста и другими возможными проблемами. Такое тестирование является важной частью общего тестирования юзабилити.
Видео курсы по схожей тематике:
Автоматизация тестирования мобильных приложений
Этап 6: Тестирование производительности
Мобильные устройства предоставляют для приложений меньший объем памяти и меньшую доступную мощность процессора, чем стационарные компьютеры и ноутбуки. По этой причине в работе мобильных приложений очень важна эффективность использования предоставляемых ресурсов. Вам следует проверить работоспособность тестируемого приложения, изменив соединение с 2G, 3G на WIFI, проверить скорость отклика, потребление заряда батареи, стабильность работы и т. д.
Рекомендуется проверять приложение на предмет масштабируемости применения и наличие возможных проблем с производительностью.
В рамках этого этапа важно пройти и нагрузочное тестирование мобильного приложения.
Функциональное тестирование
Функциональное тестирование мобильного приложения, по большей части, может быть выполнено так же, как вы выполнили бы его для любого другого типа приложения. По этой причине мы не будем вдаваться в подробности этого типа тестирования. Однако следует указать области, которые имеют особое значение для мобильных приложений.
Имейте в виду, что функциональное тестирование должно включать в себя тестирование всех функций приложения и не должно быть излишне сосредоточено на какой-то одной функции.
В рамках функционального тестирования, вам следует выполнить следующие тесты:
Этап 7: Аттестационное тестирование и тестирование безопасности приложения
Безопасность и конфиденциальность данных имеют огромное значение в наше время. Пользователи требуют, чтобы вся их информация хранилась безопасно и конфиденциально.
Убедитесь, что тестируемое приложение надежно защищено. Выполните проверку на возможность внедрения SQL инъекций, на возможность перехвата сеансов, анализа дампов данных, анализа пакетов и SSL трафика.
Очень важно проверить безопасность хранилища конфиденциальных данных вашего мобильного приложения и его поведение в соответствии с различными схемами разрешений для устройств.
Помимо проверки безусловного шифрования имен пользователей и паролей, задайте себе следующие вопросы:
• Есть ли у приложения сертификаты безопасности?
• Использует ли приложение безопасные сетевые протоколы?
• Существуют ли какие-либо ограничения, например количество попыток входа в систему до блокировки пользователей?
Этап 8: Тестирование устройства
Выполните тесты по тем алгоритмам, которые вы ранее прописали в тестовых случаях и сценариях тестирования на всех определенных для тестирования устройствах, в облаке и / или на физических устройствах.
Этап 9: контрольный этап и резюме
Этот этап включает в себя подробное и полное тестирование - от ранних итеративных этапов тестирования до регрессионных тестов, которые все еще могут потребоваться для стабилизации работы приложения и выявления незначительных дефектов.
На этом этапе тестирования вы можете добавить для проверки новые функции и изменить настройки на те, которых не будет в финальной версии.
После завершения тестирования приложения, дополнительные параметры и функции, добавленные для проверки на этом этапе, удаляются, и окончательная версия становится готовой для представления общественности.
Итоговый отчет о тестировании
Весь процесс тестирования мобильных приложений должен быть тщательно задокументирован. Проверьте дважды, сделаны ли нужные записи, и после этого сформируйте свой окончательный отчет о тестировании (test summary report).
Этот отчет должен включать:
• Важную информацию, выявленную в результате проведенных испытаний;
• Информацию о качестве проводимого тестирования;
• Сводную информацию о качестве тестируемого мобильного приложения;
• Статистику, полученную из отчетов об различных инцидентах;
• Информацию о видах тестирования и времени, затраченном на каждый из них.
Следует также указать в отчете, что:
• данное мобильное приложение пригодно для использования в том качестве, в котором заявлено;
• соответствует всем критериям приемлемости функционала и качества работы.
Бесплатные вебинары по схожей тематике:
QA практикум. Техники тест дизайна. Часть 1
Средства автоматизации тестирования REST API
QA практикум. Техники тест дизайна. Часть 2
Вооружившись сводкой, руководство проекта теперь может решить, готово ли мобильное приложение к выпуску на рынок.
Тестирование мобильных приложений - сложная задача. Приспосабливая эти этапы тестирования к каждому разрабатываемому приложению и тщательно выполняя каждый шаг - вы гарантированно получите полнофункциональный качественный продукт.
В данной статье мы рассмотрели особенности тестирования мобильных приложений. Рассмотренные этапы тестирования важны и для тестирования андроид приложений и как ответ на вопрос как тестировать приложения для iphone.
Важно помнить, что тестирование приложений перед представлением на рынке – важный этап в разработке любых приложений. И, конечно же, тестирование мобильных приложений имеет свои особенности и важные моменты.
Ответственно подходите к вопросу разработки и тестирования мобильных приложений, своевременно изучая и применяя актуальные методики и технологии. С нашей стороны мы рекомендуем для изучения курс на ITVDN - Unit тестирование для Android разработчиков.
Читайте также: