Пока нет оценок.
Пожалуйста, подождите...

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

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

Как правильно облегчить процесс тестирования?

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

Далее, не забывайте о логах, скриншотах и видео — это самые лучшие «доводы» от тестировщика!

Очень жаль, что с логами «общения» с используемым сервером, порой, не все так хорошо, как с клиентскими логами.

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

На заметку:

  1. Старайтесь просить программистов выводить в понятный интерфейс для ознакомления с логами все существующие запросы к серверу и ответы, которые поступают от него. Подобным образом будет проще проводить анализ запросов и ответов от сервера, обнаруживать дубликаты, искать эффективные способы выполнения обновления ПО;
  2. Приучите себя создавать клиентские логи самостоятельно — масса логов тоже очень вредное явление и попросту забивает консоль.

Не забывайте об использовании UIAutoMonkey (https://developer.android.com/studio/test/monkey) в качестве инструмента нахождения зависаний, пока вы выполняете тестирование приложения.

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

К слову, Testfairy, с недавнего времени, работает и на iOS, но с несколько ограниченным функционалом.

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

Один или два тестировщика просто физически не смогут покрыть тестами все комбинации тест-кейсов на разнообразных устройствах (особенно, если продукт нацелен на работу от самых старых версий мобильных операционных систем).

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

Очень хорошо, когда есть отладочное меню с параметрами, которые могут облегчать работу программистам и тестировщикам (особенно, когда дело касается команды автоматизаторов).

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

Тестирование на эмуляторах и симуляторах — это все для тестировщиков мобильного ПО. Это очень сильно облегчает процесс проверки мобильных программ.

К примеру, для iOS подобным образом очень просто тестировать изменения местоположения и некоторые обновления местоположения.

Под Андроид можно запросто конфигурировать разные параметры нужного устройства: от разрешения экрана, плотности пикселей и до количества ОЗУ.

Также помните о том, что стоит заполнять ОЗУ устройства перед стартом работы программы. Данная процедура помогает, во-первых, в проведении стресс-тестирования и тестировании скорость работы ПО, а во-вторых — завалидировать процесс сохранения и возобновления работы продукта (например, после быстрого сворачивания и развертывания приложения).

Ну и в дополнение, помните, что всегда необходимо запускать программу под отладчиком:

  1. Это даст вам возможность работать медленно с приложением — это порой открывает новые баги;
  2. Если в продукте произойдет сбой — он сразу остановится, и вот тогда можно будет позвать разработчика (по возможности) для отладки сразу, не отходя от рабочей машины.

Взаимодействие с сетью

Тестируемое ПО должжно стабильно функционировать при:

  • Нестабильном соединении с Интернетом;
  • Отсутствии соединения с Интернетом;
  • Очень медленной скорости соединения;
  • Некорректном ответе от сервера;
  •  Неожиданной смене вида соединения (с 4G на Wi-Fi, и наоборот).

Применяйте цепочки тест-кейсов «неполадки с сетью», по максимуму прорабатывая всевозможные сценарии:

  1. Выборочную прошивку роутера, чтобы можно было быстро корректировать нужную скорость Интернет-соединения;
  2. Прокси-сервер;
  3.  Network Link Conditioner (http://nshipster.com/network-link-conditioner/) — с его помощью можно создать Интернет-трафик и «раздавать» сеть на основе точки доступа как на iOS-устройстве, так и на Mac;
  4.  Под Андроид рекомендуется использовать установки скорости Интернет-соединения внутри эмулятора.
Оптимизация процесса тестирования мобильного продукта

Оптимизация процесса тестирования мобильного продукта

Взаимодействие с данными ПО, внешними и внутренними сервисами

Если на вашем проекте есть сторонний сервис — на него не стоит полагаться на 100%.

Это значит, что правильнее всего будет заранее найти максимальное число чрезвычайных ситуаций и проанализировать шаги для их исправления. Заранее учесть обработку неожиданных ответов (системные ошибки, кэши, пустые ответы и прочее) с точки зрения сторонних сервисов, с индикацией проблем пользователю.

Если вы работаете со сторонними библиотеками — они точно будут способствовать возникновению непредвиденных ситуаций.

К примеру, очень часто в тех же PayPal, Twitter и Facebook встречается масса багов (часто падают библиотеки и «утягивают» за собой приложение).

Если ваше тестируемое ПО обновляет данные по статическим, и простым ссылкам, то, как вариант, можно применять Google Drive or Dropbox на время, пока логика сервера не готова к работе или же, банально, не обкатывается. «Заливать» или обновлять файлы на устройстве — процесс очень сомнительный.

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

В качестве яркого примера — баг с LinkedIn, когда часть пользователей не смогла открыть приложение, пока разработчики не выкатили новую версию продукта (время исправления составило более одного дня).

Оптимизация процессов тестирования

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

Создайте культуру предварительного тестирования

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

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

Никто же не хочет выставлять свои неразумные ошибки на всеобщее обозрение.

Старайтесь задавать разработчикам как можно больше наводящих вопросов

Таким образом вы не просто «поднимите» свой авторитет как тестировщика — вы также будете пытаться разобраться в программном коде и сферах, которые затронуты тестируемой  особенностью ПО.

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

Постарайтесь изучить жизненный цикл приложений

Это необходимо для понимания того, в какое состояние может переходить экран приложения во время тестов.

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

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

Выводы

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

Также из данной статьи что-то полезное могут почерпнуть программисты и менеджеры проектов.

 

Оставить комментарий