|
 Автор: Максим Железный, QA инженер, www.linkedin.com/in/maxzheleznyy, twitter.com/MaxZheleznyy
Оригинальная публикация: https://habrahabr.ru/company/tdb/blog/337234/
Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе.
Если разбить статью на части, то она будет выглядеть так:
- Источники информации для максимально успешного тестирования
- Инструменты для упрощения жизни тестировщика
- Hint’ы
- Доставка и анализ приложений
- Куда расти дальше, если постигли дзен
//Алярма — ниже параграф для менеджеров и ценителей статистики
В этой статье я не буду рассказывать что такое iOS и Android, но нельзя не сказать, какую важную роль играют мобильные платформы в нашей жизни. Если обратиться к статистике по продажам PC и смартфонов, то мы можем увидеть, что с каждым годом количество мобилок растет, а вот PC все меньше пользуется спросом. Однако не стоит разводить полемику о смерти какой-либо из платформ. Как отлично было сказано в статье Пола Адамса — каждому бизнесу стоит найти свой идеальный баланс между мобильным и стационарным типом работы с информацией. А пока менеджеры убежали решать вопросы бизнеса, я продолжу.
//Параграф для менеджеров закончился
Источники информации для тестирования
В каком-то смысле тестировщик должен быть маленьким специалистом в каждой отдельной области, наподобие перочинного ножа. Чтобы всегда быть в курсе событий, нужно заручиться определенными источниками информации.
- Это страницы строгих гайдлайнов от Apple и Google по публикации в магазинах приложений. В целом правила во многом перекликаются и достаточно тривиальны, однако, как говорится, дьявол кроется в деталях. Именно эти детали вам лучше всего всегда отслеживать. Ведь если ваше приложение работает с данными пользователя, производит денежные транзакции или просто предоставляет контент для детей, то в день релиза готовьтесь увидеть отклонение из-за маленькой юридической мелочи, о которой вы, как тестировщик, должны были подумать вместе с менеджером и разработчиком.
- Также стоит следить за дизайнерскими гайдлайнами от тех же Apple и Google. Безусловно дизайн ревью является задачей дизайнера, однако полученные в этих гайдлайнах знания позволят вам лучше понимать чего ждет от вас конечный пользователь, позволит лучше разобраться в философии платформы, а также, впоследствии, даст возможность проводить качественные UI и UX тесты.
- Обязательно просматривайте все технические конференции Apple и Google, ведь именно на них можно узнать куда движется каждая платформа, какие новые инструменты она предоставляет как пользователям, так и разработчикам. Вас должны интересовать любые инструменты, ведь каждый из них либо будет создавать итоговый продукт, либо сам будет являться целью вашего тестирования.
- Просто необходимо читать как можно больше книг о тестировании и разработке ПО, различных блогов на хабре и других источниках [здесь могла быть ваша реклама]
Инструменты для упрощения жизни тестировщика
Жизнь тестировщика разнообразна и многогранна. Для того, чтобы не утонуть в потоках информации и быть максимально эффективным, существует множество техник и инструментов.
- Ведение тест кейсов и хранение тикетов. Один из итоговых выхлопов любого тестирования — тикеты в специальных программах. Каждый баг не только хочет, чтобы вы его нашли, но и задокументировали. Для этого было создано огромное количество инструментов различного рода сложности и платности. Среди наиболее популярных можно выделить Jira, RedMine, TestTarantula, TestLink, TestCollab, QACoverage. Главная проблема данных сервисов в том, что они очень похожи на звезды на небе — их бесконечное множество и все они схожи со стороны, но стоит присмотреться поближе, и их разница уже не оставляет сомнений. Также для исследовательского тестирования мы используем Rapid Reporter. С помощью него можно быстро записывать все “шероховатости”, которые вы заметили при путешествии по приложению.
- Чтобы ничего не забыть в процессе тестирования стоит использовать одну из интеллектуальных карт и эвристические шпаргалки. Важно заметить, что обе они лишь помогают вам не пропустить что-то важное. Если какой-то из пунктов вам кажется излишним для конкретного проекта, то вы всегда можете создать собственные эвристики или карты.
- Немного математики и логики — если перед вами стоит задача протестировать 4 разных поля ввода + различные их комбинации друг между другом, то на помощь приходит метод PairWise’инга. С помощью этого инструмента вы всегда сможете сформировать набор уникальных и самодостаточных тест кейсов.
- Обязательно вооружитесь инструментами для логирования, записи экрана и скриншотером. Подойдут как зашитые в ОС инструменты, так и программы от сторонних разработчиков.
- Немного автоматизации рутины, а именно генерация рандомной информации, создание почты, базовая проверка на корректность именования вашего тикета.
- Еще немного автоматизации с помощью “обезьянок” — простого в использовании механизма протыкивания всего приложения. Есть версии как для ios, так и для android. Однако, стоит заметить, что обезьянка дает небольшой выхлоп, каких-то фундаментальных крашей словить с ней не получится. Относительно успешно подобные обезьянки помогают решить задачи, связанные с нагрузкой на приложение (как оно себя поведет, если 1000 раз нажать на одну кнопку).
- Подружитесь с Android Studio и Xcode, ведь в них вы сможете не только производить белоящечное тестирование, но и полноценно поработать с дебаггером и брейкпоинтами.
- Манипуляции с сетями — большинство современных приложений плотно завязаны на работе с сетью, поэтому будет вполне разумно использовать такие инструменты как
- Network Link Conditioner — удобный и крайне простой инструмент для установки требуемого соединения. Нужна имитация плохой связи на реальном девайсе? Пожалуйста. Хотелось бы протестировать как будет вести себя приложение при потере части пакетов данных? Без проблем.
- Для android все несколько сложнее. На самом девайсе подобных настроек вы сделать не сможете, поэтому вам либо нужно будет использовать эмулятор девайса со специальной настройкой, либо применить Network Link Conditioner (см. пункт выше) на реальном iOS девайсе + с него же установить режим Hotspot’a. Достаточно костыльный метод, но зато гарантированно позволит проверить поведение реального android девайса без фольги и клеток Фарадея.
- Также стоит вооружиться сервисами проксирования данных Fiddler или Charles — оба по своему прекрасны. Если вам необходимо посмотреть за отправляемыми/получаемыми данными приложения через сеть, то лучшего инструмента не найти. Каждый из них будет выполнять функцию man-in-the-middle, что позволит вам не только просмотреть все содержимое пакетов данных, но и даст возможность почувствовать себя юным хакером.
P.S. также слышал про WireShark, но ознакомление с ним оставляю вам как домашнее задание ;)
- Симуляторы и Эмуляторы — лучшие друзья тестировщика с маленькой фермой девайсов. Если вы встретитесь с багом, который появляется только на каком-нибудь экзотическом виде разрешения (см.китайские смартфоны), то вам смогут помочь AVD и Genymotion для Android, а также Simulator в Xcode для iPhone. Важно заметить, что симуляторы и эмуляторы не смогут заменить вам реальных девайсов, ни в коем случае не считайте, что успешные тесты на симуляторах = успешные тесты на реальных девайсах.
- Последний тип инструментов абсолютно незаменим в случае, если вам требуется тестировать API. Поскольку многие мобильные приложения представляют из себя большой программный пласт из запросов к серверу и обработку полученных ответов, то разумно было бы нам, как тестировщикам, проверять что же такое присылает сервер из своих API методов. На помощь в этой задаче могут прийти такие продукты как Paw, Insomnia, SoapUI и, мой личный фаворит, Postman. На первых порах все что вам может понадобиться от каждого из них — так это форма различного запроса к серверу(Get, Put, Post, Delete) и получаемый ответ. Если на запрос вы получаете валидный ответ, то можно
вздохнуть спокойно и пойти выпить чаю продолжить тестировать дальше. Hint’ы
В любом виде тестирования есть исторически сложившиеся bottle neck’и зная которые можно за максимальное короткое время находить большую часть ошибок. Также тут я попытался описать некоторые рабочие моменты, которые упростят поиск ошибок.
- Всегда проверяйте работу приложения в режимах портрета и ландшафта. Порой разработчики забывают отключить поддержку ландшафта или элементарно пропускают верстку какого-нибудь из необходимых элементов. Не очень приятно узнавать, когда любимая программа крашится при малейшем повороте экрана.
- Обязательно посмотрите как ведет себя приложение после перехода в сон, сворачивания, возвращения в активный режим и резком выходе из активного режима (звонок по телефону). Для Android есть даже специальная опция в настройках — Do not keep activities (DNKA). Обязательно тестируйте ваше приложение с включенным и выключенным DNKA, это значительно сокращает время проверок работы с активностями. Подсказка — заводя тикеты по багам, которые были найдены с помощью DNKA, не поленитесь указать, что использовали этот инструмент, так разработчику будет проще воспроизвести вашу ошибку.
- Огромное количество приложений использует сервисы ОС. К ним относится камера, телефонная книга, микрофон и тд. В Android пользователь дает доступ к данным сервисам при загрузке приложения, а в iOS (а также в Android начиная с версии 6.0) разрешения даются уже после запуска программы. Все это означает, что нам нужно проверять не только текст запросов на сервисы (согласитесь, что беспричинный запрос на доступ к камере выглядит странно), так еще нужно проверять и работу системы, если разрешение было не дано. В качестве жизненного примера я всегда вспоминаю, как приложение для интернет звонков под кодовым именем “N” падало, если не давать ему доступ к микрофону.
- Нотификации/уведомления — как много в этих словах. Имея дело с уведомлениями вам всегда нужно помнить, что они могут быть как локальные, так и серверные (т.е. завязанные на подключении к сети). Кроме того, уведомления, в идеале, должны вести на тот экран, о котором говорится в уведомлении. К сожалению, крайне распространена практика, когда нажимая на уведомление типа “Эй, вам пришло сообщение от Васи”, вы попадаете на главный экран приложения, а не к столь желанному сообщению от Василия.
- Выше я уже писал, что для тестов, связанных с сетью, есть специальные инструменты, но хотелось еще раз напомнить и указать, что проверка того, как приложение реагирует на разные виды связи и переходы из одного состояния в другое, — чрезвычайно важны. Большинство пользователей мобильных устройств не сидят в уютном офисе рядом с wifi роутером, а идут по улице или едут в метро. Держа это в голове вы всегда сможете найти краши вашего приложения там, где ленивый их бы просто не заметил.
- Крайне важно посмотреть как поведет себя приложение, если вы быстро будете переходить между двумя экранами (вспоминаем monkey test выше). По опыту скажу, что в Android чрезвычайно огромное количество ошибок находится именно из-за того, что при быстром переходе между двумя экранами необходимые поля не успевают заполниться данными и, в последствии, приводят к крашу.
- Не могу не сказать о сертификатах. Разработчики мобильных приложений используют разные сертификаты для подписи разрабатываемого продукта (сертификат store и тест). Большую часть времени вы будете видеть приложение, которое было подписано сертификатом для теста, но когда дело дойдет до проверки версии с другим сертификатом — не поленитесь провести полный регресс приложения, ведь не раз получалось так, что полностью работоспособное приложение начинало падать при запуске из-за смены сертификата.
- Смена языка и времени устройства (особенно времени). Никогда не рассчитывайте на то, что все пользователи будут синхронизированы с сетью и автоматически перейдут на корректный часовой пояс. Если же ваше приложение как-либо должно меняться со временем (например доставка еды через 30 минут), то тут у вас бескрайний простор для деятельности.
- Всегда общайтесь с менеджерами и разработчиками. Несколько минут неформального общения о новой сборке смогут открыть для вас много нового, а заодно и упростят жизнь. Также, перед началом проверки билда, рекомендую спрашивать у разработчиков — чтобы они проверили на вашем месте, что они уже смотрели и почему уверены, что это должно безотказно работать. Главное — не попадайтесь на рассказы об отказоустойчивости и максимальной стабильности, таких продуктов природа еще не произвела.
- Старайтесь грамотно прогнозировать время для тестирования, и, что не менее важно, умейте его придерживаться. Найдите свой темп работы, войдите в него и постепенно улучшайте. В конце-концов — научитесь останавливаться и переключаться между задачами.
Доставка и анализ приложений
Доставка приложений на тестовые девайсы является очень важной частью тестирования, ведь вы не сможете проверить последний актуальный билд, пока он не попадет к вам в руки. Именно для решения этой проблемы на помощь приходят различные сервисы. Ниже я поделюсь теми, которые мы успели не только попробовать в деле, но и найти идеальное место в процессе разработки для каждого из них.
- TestFlight и Бета тестирование в Play Market — отличный инструмент для проверки работоспособности билдов после накатывания на старые версии приложения, которые вы ранее уже зарелизили. Эти способы дистрибуции подразумевают, что большая часть приложения уже протестирована, поэтому использовать их на ранних стадиях проекта бессмысленно.
- HockeyApp, AppBlade, Appaloosa, TestFairy — удобные инструменты для дистрибуции билдов как для iOS, так и для Android. Каждый из них поддерживает возможность скачивания прошлых сборок, а некоторые даже позволяют собирать аналитику по использованию и крашам. Данные инструменты можно использовать как на самых ранних стадиях, так и перед релизом. Также нельзя не отметить, что многие энтерпрайз заказчики останавливаются на распространении своих приложений именно через вот такие сервисы, поэтому не удивляйтесь, если какие-то из ваших продуктов так никогда и не доберутся до App Store и Play Market, а останутся в рамках одного из этих сервисов.
- Google Drive, Яндекс Диск, [подставить свое] — сервисы из второго пункта могут быть заменены обычным облачным хранилищем, но в таком случае управление и контроль за версиями лягут на ваши плечи. Если вы чувствуете себя достаточно
безумным организованным, то можете попробовать построить все процессы на облачных дисках. Мы в Trinity Digital используем данные сервисы, когда нужно сделать резервную копию определенной версии приложения, либо при тестировании на совсем ранних стадиях разработки.
Не менее важным инструментом является и анализ приложений, в конце-концов кто предупрежден, тот вооружен. Именно поэтому перед выпуском продукта (а лучше и перед началом разработки) стоит определиться с теми сервисами, которые позволят лучше всего держать руку на пульсе вашего приложения. Здесь я также несколько продолжил тему источников информации из прошлой главы.
- CrashLytics, Bugsee, AppSee и FireBase — дают очень подробный анализ по использованию ваших приложений, практически моментально сообщают о крашах, и, конечно же, преисполнены различных графиков и диаграмм. Каждый из них, безусловно, имеет свои уникальные фишки. Так, например, Bugsee дает возможность тестировщику создавать тикет с записью ошибки прямо из мобильного устройства с открытым приложением, а FireBase изначально создан, как средство быстрого разворачивания backend’а. Учитывая все эти особенности и фишки, вы сможете выбрать более подходящий для вас инструмент.
- Отзывы в App Store и Play Market — в отличие от наших коллег из мира web’а, мы всегда можем посмотреть на реальное мнение наших пользователей. Будут ли вам писать о позитивных вещах столько же, сколько о негативных? Вряд ли. Всегда ли будут негативные отзывы полезны? Сомневаюсь. Будет ли затраченное на отзывы время стоить того? Безусловно, если вы хотите сделать действительно качественный продукт, который интересен пользователям. Однако тут стоит указать, что если вся команда не настроена на работу с отзывами, то одной вашей инициативы будет недостаточно. Культивируйте и прививайте любовь к отзывам и работе с ними — это обязательно окупится в долгосрочной перспективе.
- Внедрите в каждое приложение формы обратной связи — так пользователь всегда сможет связаться с вашей командой, не портя рейтинг в магазине приложений + самому пользователю будет проще ориентироваться в истории email переписки, а не безликом stor’е.
- Рано или поздно вам обязательно потребуется организовывать ферму девайсов. Не буду вдаваться в подробности, но, если коротко, то вам обязательно нужно будет учитывать такие факторы как популярность девайсов в вашем регионе, популярность девайсов у аудитории вашего приложения, недостающие ОС и размеры экранов, которые вызывают проблемы больше всего, тенденции моды на ближайшие два года (ибо девайсы вы не на месяц себе берете), и, конечно же, нужно всегда держать в голове, что у Android смартфонов есть огромное количество производителей, каждый из которых считает своим долгом — внедрить кастомную прошивку
с максимальным количеством конфликтов для внешних библиотек. На помощь в этой непростой задаче вам должны приходить ваши аналитики, а также такие сервисы, как
Куда расти дальше
Все мы начинаем с мануального тестирования, но редко кто остается в той же должности на протяжении долгих лет. Так куда же двигаться тестировщику, когда все инструменты из списка уже изучены и хочется чего-то нового? По сути, каждый тестировщик в итоге движется по одному из следующих путей — разработка, автотесты, управленец, DevOps. Какой бы из путей не был бы вам по душе, их все объединяют некоторые качества, которые должны присутствовать в каждом уважающем себя профессионале.
- Системный подход — любой уважающий себя тестировщик должен системно подходить к проблемам. Обращайтесь к математическим анализам и статистике как можно чаще, они дадут больший простор для профессионального роста. Сюда же стоит отнести работу с рисками, приоритизацию и аналитику.
- Коммуникация — тестировщик не стоит и гроша, если не может грамотно рассказать о результатах своего теста. Подтягивайте как родной язык, так и зарубежный. Чем выше ваши коммуникативные навыки, тем быстрее и лучше будут закрываться баги.
- Управление командой — рано или поздно вам придется управлять определенным количеством людей из вашей сферы деятельности. Начинайте смотреть как организованы команды в других компаниях, почему некоторые подходы стоит использовать, а некоторые можно пропустить.
- Автоматизация — не стоит думать, что автоматизация, это только написание горы кода и полная замена мануального труда. Вы можете оставаться мануальным тестировщиком, но знать как с помощью python’а быстро заполнять 50 различных полей, которые вам так лениво каждый раз заполнять самостоятельно. Автоматизация ли это? Безусловно, хоть и базовая. Не бойтесь автоматизации, а всячески осваивайте ее, пусть и маленькими шагами.
- Тренды — обязательно смотрите на приложения конкурентов, победителей различных номинаций у Apple и Google, следите за трендами в социальных сетях. Может ваша первичная задача — качество, но, зная проблемы конкурентов, можно избежать проблем у себя.
- Программирование — научитесь программировать. Это не только поможет вам с автоматизацией, но и позволит разговаривать с разработчиками на одном языке. Я не стану расписывать, как важно знать языки программирования, просто держите у себя в голове, что это важный скилл, без которого дальше будет только сложнее.
Заключение
Как я говорил в самом начале статьи — я попытался сделать маленький список всего самого необходимого для начинающего мобильного тестировщика. Теперь окидывая статью своим пристальным взглядом, я понимаю, что вся статья отлично отображает само тестирование как феномен. Сначала может показаться, что оно крошечное, но с каждым новым шагом обрастает новыми деталями.
В качестве финального слова хочу пожелать вам побольше девайсов на ферму, поменьше финальных правок и максимум удовольствия от процесса.
P.S. а послесловием выступит напутствие почему при тестировании важно оставаться внимательным не только к экрану смартфона:
 Обсудить в форуме
|
