10 советов успешного тестирования

 

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

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

  1. Храните ваши девайсы на расстоянии вытянутой рукиДавайте перефразируем Тайлера Дердена из Бойцовского клуба и проясним — два самых важных правила при тестировании мобильных приложений:

    1. Никогда не используйте эмуляторы.
    2. Никогда не используйте эмуляторы.

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

    Следующие три правила продолжают тенденцию:

    1. Всегда используйте более одного устройства.
    2. Всегда используйте более одного размера экрана или разрешения.
    3. Всегда используйте более одной версии ОС.

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

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

 

  1. Тайм-менеджмент — ключ к успеху

Если вы тестируете версию v2.2-42 вашего приложения, а весь ченджлог состоит из «исправили переключатель отключения звука», нет смысла тратить 10 часов на каждый сценарий использования, связанный с вещами, которые не имеют ничего общего с этим фиксом. Если ваши разработчики регулярно используют бета-сборку, вашей работой будет проверять исправления ошибок и дополнений. Вы можете быстро проверить основные функции приложения, чтобы узнать, не затронуто ли что-либо еще (дымное тестирование), но оставим остальное на потом.

Тем не менее, если вы тестируете версию 3.0, у которой есть сводка изменений размером с вашу ногу, быстрой проверкой фиксов вы не обойдетесь. Независимо от того, протестировали ли вы каждый шаг или нет, вы должны, вероятнее всего, выполнить полное (регрессионное тестирование). Новые функции должны плавно интегрироваться со старыми, неприятные вчерашние баги должны оставаться вне поля зрения, и приложение должно вести себя как единое целое. Проверьте всё полностью: потратьте время и силы, чтобы заглянуть под каждый камень. Отбросьте тот факт, что ваш разработчик может проявить серьезную ненависть к вам из-за сообщений об ошибках, которые продолжают приходить. Больше ошибок, сообщаемых командой по обеспечению качества, означает меньше ошибок, о которых сообщает конечный пользователь, и это делает всех счастливыми.

  1. Всегда проверяйте функционал

Ваше приложение используется для поиска и покупки билетов на джазовые концерты? Тогда пользователь должен будет найти и купить билеты на джазовые концерты. Как бы ни было просто или сложно, приложение должно делать то, что пользователь собирается делать изо дня в день.

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

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

  1. Всегда учитывайте User experience.Тестирование юзабилити является еще одним краеугольным камнем тестирования мобильных приложений, и оно касается тех параметров, которые трудно измерить или классифицировать. Мобильные устройства небольшие и имеют очень мало физических кнопок, поэтому приложения требуют дополнительных усилий, чтобы стать приятными и удобными. Задавайте себе следующие вопросы при тестировании приложения:

    Является ли это приложение быстрым и интуитивно понятным или медленным и сложным?

    Является ли навигация простой и понятной?

    Это хорошо выглядит и есть ли какие-либо смещения элементов или проблемы с текстом?

    Буду ли я когда-либо устанавливать и пользоваться им?

    Это приложение делает меня счастливым?

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

  2. Не пытаться исправлять багиПредложите помощь разработчику, если у вас есть свободное время и у вас есть ноу-хау, но вы никогда не должны исправлять код других людей, лезть куда не нужно или отслеживать трафик API. Вы должны сообщить, что пошло не так, и как это произошло. Часто лучше оставить вопрос “почему” для тех, кто имеет более широкое понимание основной логики. Относитесь к своему приложению как к черному ящику и держитесь как можно нейтральнее.

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

  3. Оставайтесь терпеливымДьявол кроется в деталях, и 9 из 10 спешек ни к чему не приведут. Существует несколько подходов к тестированию, но ни один из них не включает в себя лень. Вот несколько вопросов, которые вы должны постоянно задавать себе:

    Я пропустил важный сценарий?

    Я понимаю, что приложение должно делать?

    Я просто просматриваю приложение или внимательно изучаю?

    Могу ли я различить ошибку и функцию?

    Иногда вы можете переоценить свое знакомство с приложением и предположить, что что-то работает. Никогда не предполагайте, что это работает, всегда предполагайте, что это не работает.

  4. Нагрузите ваше приложение

    Хотите знать, насколько устойчивым является ваше приложение? Проведите деструктивное тестирование. Попытайтесь воспроизвести максимально неадекватное поведение пользователя. Еще лучше, запустите Monkey test, пока вы придумываете что тестировать дальше. Никаких сбоев или зависаний? Угостите своих разработчиков освежающим напитком, они заслужили это. 

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

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

  5. Учтите все сценарии работы интернета

    Большинство приложений сегодня будут общаться с сервером и, следовательно, ожидать какого-то подключения к Интернету. Это имеет решающее значение и нуждается в тщательном тестировании. Средний пользователь будет использовать ваше приложение в сетях от великолепно быстрого Wi-Fi до медленного медленного EDGE (названного так, потому что он оно доводит вас до самого края). Некоторые могут запускать приложение офлайн; некоторые могут попасть в туннель или подвал и потерять связь; другие могут быть довольно упрямыми и поддерживать живое общение и отключение от Интернета. Независимо от этого, ваше приложение должно работать во всех случаях. Если нет связи, пользователь должен знать о проблеме. Не должно быть никаких сбоев, и анимация загрузки не должна продолжаться вечно. 

    Если ваше приложение ожидает, что Bluetooth или GPS будут работать — убедитесь, что оно также работает без него. Сообщение должно быть четко передано пользователю: «Эй, человек, пожалуйста, включите то или это, чтобы эта функция работала».

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

  6. АвтоматизируйтеВнедряйте непрерывное тестирование и позвольте вашим скриптам делать часть вашей работы. Воспользуйтесь преимуществами сценариев использования, которые вы усердно записывали и кодили или напишите несколько полезных скриптов, которые избавят вас от тестирования самых банальных и повторяющихся частей приложения. Если вы чувствуете особый энтузиазм, вы можете даже попробовать запустить свой скрипт на нескольких десятках устройств, используя ферму устройств, такую ​​как Amazon’s.

    Calabash, Robotium, Appium, Cucumber, Espresso и MonkeyTalk — это те фреймворки, которые стоит рассмотреть. Если вы тестируете многоплатформенные приложения, Calabash (только Ruby) и Appium (Ruby, Java, JavaScript, C #, PHP) лучше сделать ставку на них.

  7. Вам нужен взгляд со стороны

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

    НАКОНЕЦ, ПОЙДИТЕ ПОЕШЬТЕ
    В конце концов, все, чего мы хотим достичь, — это оказание помощи в создании приложений, которым люди будут пользоваться и поддерживать как часть своей повседневной жизни. Есть много других вещей, о которых мы могли бы упомянуть, но у каждого есть свои 10 заповедей тестирования мобильных приложений.

    Эпилог

    Одно можно сказать наверняка: тестирования невозможно избежать. Попробуйте загрузить несколько лучших приложений из App Store от Apple или в Play Store от Google. Они крашатся? Как часто? Если они вообще не сбоят — команды dev & QA, вероятно, работали в унисон, чтобы добиться этого. Приложение зависает так часто, что вы хотите его удалить? Значит тестеры где-то не выполнили свою работу. Так что не расслабляйтесь при тестировании, ваш бизнес будет вам благодарен.

 

Все посты

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

Leave a Reply

Your email address will not be published. Required fields are marked *


  • ru
  • uk
  • Your message has been sent