Dataserver lan отделы отдел разработки тестирование тестовые релизы android

Чек-лист тестирования мобильных приложений

У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.

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

Чек-лист для тестирования мобильных приложений состоит из восьми разделов:

Функциональное тестирование

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

Что проверяем?

1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы

Тестирование совместимости

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

Что проверяем?

1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)

Тестирование безопасности

Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.

Что проверяем?

1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками

Тестирование локализации и глобализации

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

Что проверяем?

1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса

Тестирование удобства использования

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

Что проверяем?

1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект

Стрессовое тестирование

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

Что проверяем?

1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)

Кросс-платформенное тестирование

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

Что проверяем?

— Работоспособность приложения на различных устройствах разных производителей

Тестирование производительности

Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.

Что проверяем?

1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)

Источник

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

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

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

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

Источник

Примеры тестовых заданий для Android и iOS

Очень часто при приеме на работу, программиста просят выполнить тестовое задание. Особенно это актуально для Juniour специалистов. В большинстве случаев необходимо создать мини приложение, где продемонстрировать свои навыки проектирования и кодирования.

Ниже представлены реальные примеры тестовых заданий для Android и iOS разработчиков, которые компании давали моим студентам. Далеко не все из них понятные и адекватные, но это то, что в реальности присылают кандидатам.

Задача 1. Приложение «Погода»

На 1-м экране (отображение) должно быть:

1. Возможность выбрать город (3-4 города)
2. Возможность выбрать сезон года
3. В зависимости от п.1 и п.2 — отображение средней температуры за сезон в городе
4. В зависимости от п.1 — отображать тип города (малый, средний, большой)

На 2-м экране (настройки) должно быть:

1. Управление списком городов (город, тип)
2. Управление температурой по месяцам

Приложение на первом экране должно отображать информацию, введенную пользователем на втором экране. Например, на втором экране вводим: город «Минск», тип «средний», температура июнь «23», июль «28», август «25». На первом экране в списке городов, должен отобразится Минск, тип «средний» и температура за сезон «лето» = 25,3 (среднее арифметическое 3-х месяцев).

Обязательно использовать паттерны:

• Lazy singleton
• Factory: получать тип города в зависимости от его названия
• Decorator: При запросе средней температуры за сезон в городе — должна быть возможность получить строку для логирования
• Observer: Дополнительно выводить сообщение, о температуре, через Snackbar
• Strategy: В зависимости от стратегии — выводить температуру в необходимом формате (градус Цельсия, градус Фаренгейта, Кельвин)

Условия:

• Без использования сети
• БД: SQLite
• Мы ожидаем выполнения задания без применения сторонних библиотек, кроме официальных (таких как AndroidX, Android Architectural Components, CoreData и т.д.)
• Результат выложить на Github.com

Задача 2. Репозитории GitHub

1. При помощи GitHub API отобразить список репозиториев у организации xxx (github.com/xxx)
2. Дизайн — полностью на ваше усмотрение
3. Код разместить на GitHub и прислать нам ссылку

Обязательно:

• Код на Kotlin/Swift
• Задействовать RxJava/RxSwift
• Покрыть юнит-тестами (UI не стоит)

Желательно:

• Обработка сетевых ошибок
• Поиск репозиториев в рамках организации по названию (просто фильтр списка подойдёт)
• MVI, MVVM, MVP — на ваше усмотрение, будет интересно посмотреть, но лучше без сторонних библиотек

Задача 3. Пользователи GitHub

Главный экран:

1. Users (список всех Github пользователей). Использовать API https://developer.github.com/v3/users/#get-all-users
2. В элементе списка отрисовать avatar, login (title), id (subtitle)
3. По нажатию на элемент списка реализовать переход на UserDetails
4. Реализовать pagination и Pull-to-refresh

UserDetails (экран с информацией о пользователе):

1. Использовать API https://developer.github.com/v3/users/#get-a-single-user
2. Поля: Avatar, Name, Email, Organization (если есть), Following count, Followers count, Дата создания аккаунта

Требования:

• Структурированный код (архитектурный паттерн на усмотрение кандидата)
• Язык Java/Kotlin/Swift
• Код поместить в репозиторий на GitHub/Bitbucket/GitLab
• Неоднозначности задания трактуются на усмотрение разработчика

Задача 4. Приложение «Вечеринка»

На экране располагаются:

1. Картинка (загружается по URL)
2. Название вечеринки
3. Имя пригласившего
4. Фото пригласившего (извлекается по URL)
5. Список гостей с фото, которые идут вместе с текущим пользователем. Фото загружаются по URL

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

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

Задача 5. Приложение из 1-го экрана

1. Необходимо создать приложение состоящее из 1 экрана
2. Реализовать данное задание с применением RxJava/RxSwift, любого DI (например Dagger 2) и MVP.

Реализовать:

• База данных 5 полей и заполнить любыми данными
• Вывод в активити или фрагмент в виде списка
• Live search по базе данных
• Реализовать сортировку, любой параметр

Задача 6. Приложение «Авто»

Приложение, должно иметь следующие функции:

1. Отображение списка автомобилей с характеристиками (10-12 автомобилей, 3 производителя, 1-3 марки у каждого производителя)
2. Добавление нового автомобиля
3. Редактирование деталей автомобиля

Желательно:

• Фильтрация по производителю и марке
• Сортировка по цене

Задача 7. Проверка адреса email

Создать хороший UX для пользователей, вводящих адрес электронной почты и пароль при регистрации в приложении.

Требования:

1. Проверка формата электронной почты. Пример: [email protected] не является действительным адресом электронной почты
2. Пользовательский интерфейс должен показывать, действителен или нет адрес электронной почты. При необходимости интерфейс должен указать, что не так с адресом
3. Автозаполнение и проверка доступности домена. Пользователи часто опечатываются при вводе адреса. Например, указывают неправильно доменное имя (gmail.con вместо gmail.com)
4. Проверка пароля. Нет ограничения на вводимые символы. Есть ограничение минимальной и максимальной длины
5. При необходимости, интерфейс должен указать, что неправильно
6. Проверить, что заполнены все поля, и указать, какое именно не заполнено

Для автозаполнения необходимо:

• Проверить существование введённого домена
• Указать, что неправильно в введённом имени
• Предложить Автозаполнение доменного имени самыми вероятными и популярными доменными именами. Пример: если пользователь вводит «[email protected]», то продолжениями могут быть «[email protected]», «[email protected]» и т.д. Если пользователь уточняет «[email protected]», то продолжениями могут быть популярные домены, начинающиеся с «g». Например: «[email protected]», «[email protected]»

Источник