Стратегия
разработана, тестовая документация
написана. Можно переходить к
тестированию вашего приложения.
Как мы уже говорили, мобильные приложения обязательно тестируются на нескольких устройствах. Наш опыт подсказывает, что значительное количество дефектов не зависит от окружения, т.е. они воспроизводятся на всех устройствах. В связи с этим нет необходимости проводить на каждом устройстве все типы тестов.
Обычно активности по первичному тестированию приложений включают полный тест и тест совместимости.
- Полный тест предполагает проверку всей функциональности приложения: проверки по позитивным и негативным сценариям, взаимодействие функций приложения и пользовательского интерфейса, специфические проверки для мобильных устройств. Кроме того, полный тест включает в себя проверку соответствия приложения стандартам iOS и Android в области разработки интерфейса мобильных приложений (iOS Human Interface Guidelines, Android User Interface Guidelines).
- Тест совместимости включает проверку только основной функциональности приложения, а также отображение на мобильных устройствах с отличиями в аппаратном обеспечении, характеристиках экрана и др. Данный тест включает только позитивные сценарии и не предполагает проверок нестандартных вариантов использования приложения.
Про тестирование мобильных приложений написано много, мы же хотим обратить ваше внимание на несколько нюансов, которые могут оказаться незамеченными.
- Настройте готовые точки Wi-Fi. Как уже упоминалось ранее, во время тестирования важно проверять корректную работу приложения при различных типах и скоростях соединения. Готовая Wi-Fi точка с различными настройками поможет сэкономить время на различные проверки, сэмулировать условия реальной работы устройства и выявить дефекты, которые иначе могли бы быть пропущены.
- Старайтесь проводить тестирование на двух или более девайсах одновременно. Почему это важно? За время одной проверки вы сможете протестировать сразу несколько интерфейсов.
- Если есть возможность, проведите обучение специалистов на проекте. В нашей компании существует центр компетенции по тестированию мобильных приложений, в рамках которого на регулярной основе проводятся обучающие мероприятия. На них опытные специалисты в тестировании мобильных приложений делятся своим опытом, рассказывают о мобильных операционных системах, их особенностях, показывают примеры настоящих дефектов. Также полезно будет научиться работать с различными утилитами, которые помогут собрать логи, снять скриншот, поставить билд и т.п.
- Если вы не уверены в зрелости своих процессов по тестированию, проведите технический аудит проекта. Данное мероприятие позволит определить уровень “технического здоровья” вашего продукта.
Решаем вопросы по мере их возникновения
Хорошо, если тестирование проходит согласно плану. Но бывает такое редко. В большинстве случаев вам не удастся избежать вопросов от заказчика. Давайте посмотрим, как на них реагировать.
Например, вы предложили заказчику слишком много, по его мнению, устройств. Он просит вас сократить их количество. Соглашаемся и идем от обратного. Используя всю ту же собранную статистику, убираем наименее популярные конфигурации из нашего списка.
Другой случай, требующий дополнительных разговоров: заказчик попросил провести тестирование на устройстве, которого у вас нет в наличии. Выясните, чем вызвано такое желание, и предложите альтернативу, наиболее подходящую по аппаратным и программным характеристикам.
На устройстве разработчика со стороны заказчика не воспроизводится обнаруженный баг? Такое случается. Вполне вероятно, что, если и на вашем устройстве сбросить все настройки, дефект перестанет воспроизводиться. Но это не значит, что его нет. Всегда стоит сопровождать дефекты скриншотами или видео, а также клиентскими логами. Так вы сможете избежать двойной работы и быть уверенными, что дефект не вернется к вам с пометкой “To be reformulated”.
Окончание тестирования
По окончании каждой итерации командой тестирования формируются следующие артефакты:
- Дефекты, внесенные в систему учета дефектов.
- Заполненная тестовая документация и отчет по качеству. Обычно отчет содержит оценку качества текущей версии приложения и формируется на основании количества и серьезности актуальных дефектов. сс
- Описание проблем, наиболее критичных с точки зрения конечного пользователя.
- Статистику по количеству и характеру дефектов. Это позволяет отслеживать динамику качества приложения (также эта статистика может быть использована для оценки качества работы разработчиков).
- Предложения по улучшению продукта.
- Заключение относительно степени готовности продукта к релизу.
Казалось бы, вот он и конец проекта. Парадоксально, но окончание тестирования не означает окончание работы тестировщика.
Впереди – релиз, на стадии которого никак не обойтись без специалистов по качеству ПО. В следующей статье продолжим.
