Roadmap начинающего тестировщика мобильных приложений
Проблема, с которой сталкивается любая компания или стартап при релизе мобильного приложения — необходимость проведения тестирования. Желание сэкономить на этом этапе и обманчивое чувство, что всё и так идеально работает, приводят к тому, что 25% пользователей удаляют приложение после однократного использования из-за технических неполадок.
Отказаться от проведения тестирования — это всё равно, что прийти к врачу и спросить: «Зачем сдавать все эти анализы? Может сразу перейдём к лечению?». Чтобы избежать таких косяков и выкатить достойный продукт на маркет, советуем пройтись поэтапно по всем пунктам roadmap и проверить, действительно ли в вашем приложении всё работает. В конце есть несколько незаменимых тулов, которые обязательно должен иметь в своём арсенале любой тестировщик.
Roadmap или скорее чек-листа я подготовила вместе с Таней Палун, главным специалистом по тестированию мобильных приложений в Лиге Ставок, и Владом Фадеевым, специалистом по тестированию. Наш чек-лист универсален и предназначен для тестирования общих характеристик мобильных приложений.
Шаг 0. Создание задачи в Jira Software.
Приложение Лиги Ставок тестируют 6 ручных тестировщиков и 3 автоматизатора. Чтобы не запутаться в задачах для каждого из них, мы используем джиру. Она же позволяет посмотреть, сколько времени ушло на выполнение задачи, чтобы в дальнейшем оптимизировать процесс тестирования.
Шаг 1. Изучение документации
На этом шаге тестировщик должен ознакомиться с ТЗ: как система должна работать и реагировать на ошибки.
Шаг 2. Написание набора тест-кейсов
Для тех, кто только начинает свой путь тестировщика, поясню: тест-кейсы — это некая последовательность действий, предназначенная для проверки какого-либо функционала приложения. Проще говоря — это то, какие шаги, условия, параметры позволят проверить, насколько те или иные ожидаемые результаты достижимы. Тестирование, конечно, можно провести и без тест-кейсов, но зачем, если это поможет сделать процесс обнаружения ошибок эффективнее?
Шаг 3. Проведение тестирований
*При каждом релизе мы проводим регресс, а при изменении какой-либо функциональности на бэкэнде проводим смоук — это минимальный набор тестов, которые позволяют проверить самую важную функциональность. Сейчас стараемся автоматизировать смоук на проде, чтобы каждое изменение не проверять руками.
На третьем шаге стоит сосредоточиться как минимум на трёх видах тестирования:
I. Проведение модульного тестирования
Зачем?
На этом этапе проверяем, как работают отдельные модули и компоненты мобильного приложения.
Как мы его проводим?
Этап 1. Разрабатываем тест-кейсы для проверки каждого модуля;
Этап 2. Изолируем модули друг от друга;
Этап 3. Выполняем тест-кейсы и регистрируем неудачные, чтобы исправить их.
II. Проведение интеграционного тестирования
Зачем?
Здесь мы тестируем работу программных модулей в группе и проверяем взаимодействие и обмен данными между ними на наличие багов.
Как мы его проводим?
Этап 1. Разрабатываем тест-кейсы;
Этап 2. Объединяем модули в группы;
Этап 3. Тестируем взаимодействия между различными модулями: A+B; B + C; C + D и т.д.
III. Системное тестирование
Зачем?
Когда система собрана, приступаем к системному тестированию для того, чтобы проверить, насколько функциональные и не функциональные требования к разрабатываемой системе реализованы.
IV. Проведение приёмочного тестирования
Зачем?
Приёмочное тестирование — финальный этап всего процесса. Он необходим, чтобы определить уровень готовности мобильного приложения к последующей эксплуатации и позволяет понять, соответствует ли приложение изначальной задумке разработчика.
Как мы его проводим?
Этап 1. Берём тест-кейсы, разработанные на этапах модульного/интеграционного тестирования и работаем с ними.
Этап 2. Прогоняем их перед бизнесом.
Этап 3. Принимаем решение: выпустить приложение, отправить на переработку или отказаться от дальнейшей реализации.
Когда все виды тестирования проведены, можно перейти к следующему шагу.
Шаг 4. Перевод задачи в статус «ready for regress».
И ещё немного нашей специфики.
В приложении мы также проверяем:
· Регистрацию;
· Отображение ставок;
· Совершение нескольких видов ставок;
· Отображение виджетов и разных видов предложений для клиентов по типу джекпота;
· Пополнение счёта клиентом;
· Вывод со счёта по нескольким вариантам.
Вот 4 незаменимых тула для тестировщика, которые позволят сэкономить время и деньги.
1. Charles Proxy — прокси-сервер между тестируемым приложением и сервером на стороне back-end.
Чем полезен: позволяет просмотреть весь трафик при выполнении клиент-серверных работ. Может также использоваться, чтобы протестировать функционал приложения на плохой связи, искусственно ограничивая пропускную способность канала.
Кстати, именно так мы и обнаружили недавно баги в приложении. Маркетинговые пуши работали по другой модели, ежели ожидало приложение, link для диплинка отсутствовал в блоке notification. А именно там ожидает приложение для перехода по диплинку при нажатии на пуш андроид-приложение, когда оно закрыто. Мы не могли словить эту ошибку целый год, и но теперь сможет его пофиксить и приложение будет подстраиваться под модель, которая используется в маркетинговых пушах.
2. Postman — HTTP-клиент, предназначенный для отправки запросов с клиента на сервер и обратно.
Чем полезен: помогает настроить прямую коммуникацию с сервером, изменять параметры запросов и менять их окружение, а также создавать коллекции из последовательных запросов, что значительно сокращает время тестирования.
3. Crashlytics — инструмент для создания отчётов о сбоях.
Чем полезен: выявляет возможные сбои, которые не были обнаружены во время тестирования, работая в режиме реального времени.
4. Google Analytics — инструмент для анализа всего… в том числе, для замеров работы вашего приложения.
Чем полезен: отслеживает, как пользователи используют приложение, замеряет технические параметры во время его работы (например, с какой скоростью загружаются экраны и отдельные элементы приложения), а также какие ошибки и сбои возникают при его использовании.
Если в вашей команде нет тестировщика, и вы проверяете приложения перед релизом своими силами, подходите к этому процессу философски. Тестирование ни в коем случае не должно восприниматься как процесс подтверждения правильности работы вашего приложения, потому что его главная цель — чётко и поэтапно пройтись по всем его частям, чтобы найти, в чём его работа некорректна.
