Блог A1QA

О тестировании и качестве ПО

Обеспечиваем качество мобильных приложений. Шаг 4: Релиз и тестовые активности

Продолжаем цикл статей, посвященных обеспечению качества мобильных приложений.

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

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

Задачи тестировщиков после первой итерации тестирования

  1. Проверка исправления дефектов (валидация). После того как дефект получил статус «Resolved» в баг-трекинговой системе, тестировщик должен проверить, не воспроизводится ли он снова. Если не воспроизводится, то дефект закрывается (статус «Closed»). Если проблема осталась – заводится вновь (статус «Reopened»).
  1. Тестирование новой функциональности (New Feature Testing). Если в приложении были добавлены новые функции, то их нужно протестировать на всех устройствах и заново сравнить работу приложения с предыдущей сборкой.
  1. Регрессионное тестирование. Проводится с целью оценки качества ранее реализованной функциональности и включает в себя проверку стабильности приложения после внесения изменений (добавления новой функциональности, исправления дефектов, оптимизации кода, разворачивания приложения на новом окружении).

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

Готовность приложения к релизу определяется по двум критериям:

  • Отсутствие значимых дефектов, которые оказывают влияние на работу с приложением.
  • Соответствие приложения требованиям публикации в магазине приложений. Необходимо учесть все требования App Store / Google Play / Windows Phone Store. В противном случае, заказчик рискует получить отказ в публикации приложения, даже если оно не содержит дефектов.

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

Android

iOS

  • Приложение обязано иметь уникальное имя и принадлежать к определенной категории.
  • Интерфейс приложения не должен противоречить правилам разработки пользовательских интерфейсов Human Interface Guidelines.
  • Приложение не должно содержать запрещенных материалов или полностью дублировать функциональность уже существующего продукта.

Теперь давайте подытожим и еще раз назовем особенности проектов по тестированию мобильных приложений.

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

И последняя рекомендация.

Поблагодарите свою команду

Тестирование продукта завершено? Заказчик остался доволен результатами и готовится выпустить приложение на рынок?

Передайте слова благодарности тестировщикам из команды и добавьте от себя лично, как вы ими гордитесь. Сотрудники, которых хвалят, будут впредь стараться соответствовать похвале.

Осилили все четыре статьи? Уверены, что вам будет интересно узнать, как мы применяли всю эту теорию при тестировании одного популярного приложения 2016 года. Расскажем об этом в следующей статье.

Поделиться статьей: