Home

Автор: Александр Хозя

Оригинальная публикация

Tips

1. Используйте mind-карты и эвристики/мнемоники для облегчения тестирования - все аспекты мобильного тестирования иногда сложно удержать в голове:

• Mind-карты: test insane, ministry of testing

• Мнемоники: I SLICED UP FUN, COP FLUNG GUN, SFDPOT

2. Смотрите diff-ы каждой ветки/фичи и задавайте как можно больше вопросов разработчиков. Этим вы:

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

3. Изучите жизеннный цикл приложений. Activity 1, 2, 3 (Android) и ViewController 1, 2, 3 (iOS) для понимания из какого в какое состояние может переходить экран приложения и самое приложение.

4. Попросите выводить в лог все запросы к серверу и/или попросите удобную 'смотрелку логов' у сервер-side разработчиков, чтобы удобнее было анализировать запросы и выявлять дубликаты и/или находить более удобные способы обновления данных. Например, для обновления одной части профиля разработчик может перезапрашивать весь профиль вместо использования более легковесного запроса.

5. Если у Вас есть приложение для iOS и Android, то важно соблюдать правильный баланс ресурсов для тестирования iOS и Android приложений. Цена ошибки в Android приложениях ниже:

• у Android есть staged rollout
• Android-приложение можно перевыложить хоть в тот же день или откатить staged rollout (до 50% раскладки можно полностью откатиться на предыдущую версию). Но очень часто перевыкладываться не рекомендуется, т.к. пользователи начнут жаловаться и ставить плохие оценки. Для iOS в лучшем случае через expedited review (которым очень не рекомендуют злоупотреблять) приложение будет перевыложено через 3 дня, в худшем если не разрешили expedited review - срок удлинится до 5-10 дней)
• с другой стороны iOS приложения быстрее протестировать, тк экосистема не так ужасно фрагментирована как экосистема Android. 

6. Интегрируйте систему soft- и hard-обновлений. У нас вызов soft- и hard-обновлений котролируется сервером и:

• soft-апдейт скрин можно пропускать, но он все равно будет показываться пользователю раз в 24 часа после нажатия "пропустить". Так же на нем можно просить пользователей включить авто-обновление приложений для iOS и Android в настройках системы - некоторая часть пользователей отключает авто-апдейты.
• hard-апдейт скрин нельзя пропустить и кнопка "update" ведет сразу на страничку приложения в магазине приложений

Этот механизим будет очен полезен, если необходимо чтобы все пользователи обновились на последнюю версию:

• из-за критичного бага
• для того чтобы у пользователей по всему миру была одинаковая версия приложения (например, вы выкатываете очень нужную фичу на всех платформах у которой проблемы с обратной совместимостью)
• для того того, что серверу больше не надо поддерживать старое API, которое используется только старыми клиентами

7. Приложение должно работать стабильно при:

• Нестабильном соединении
• Отсутствующем соединении
• Исключительно медленной скорости (1-2Kb/s)
• Отсутствии ответа от сервера
• Неправильном ответе сервера (мусор или ошибки)
• Смене типа соединения Wi-Fi > 3G > 4G > Wi-Fi на лету

8. Девелоперское меню iOS/Android - Ваш лучший друг. Включаем для iOS, Android

9. Парсеры должны стараться учитывать всевозможные “гадости”

10. Если приложение поддерживает портретный и ландшафтный режим – уделите смене ориентации особое внимание. 

• Может вызывать рандомные краши на iOS через некоторое время.
• Может вызывать краши, утечки памяти, возвращение к предыдущему состоянию на Android (смотрите видео).

11. Переходите между скринами много раз:

• на iOS проверяется правильность работы с памятью (не обратились ли вы к неправильному участку памяти), утечки памяти
• на Android могут быть утечки памяти, т.к. предыдущую activity что-то "держит" 

12. Если есть сторонний сервис – он будет глючить. Необходимо по-максимуму продумать все ситуации и предусмотреть workaround’ы

13. Если есть сторонние библиотеки – они обязательно будут вызывать проблемы. В частности Twitter, PayPal, Facebook довольно часто себя неадекватно ведут. Бывает, даже крашатся и "утаскивают" за собой приложение.

14. Просите разрабочиков debug-меню для себя с функциями которые облегчат им и вам жизнь. Например: фейкать ответы от сервера, открывать определенных пользователей, очищать/терять сессии, обнулять кэш.

15. Не пренебрегайте тестированием на эмуляторах/симуляторах – обычно это очень мощная штука (Android, iOS)

16. Не забывайте проверять миграцию данных/кэшей при апдейте версий. Не забывайте что пользователи могут пропускать версии и необходимо будет проверять обновления с 1.0 до 1.5. Как пример могу приветси краш на старте приложения LinkedIn в июне 2015 - часть пользователей не могли запустить приложение пока не выпустили новую версию (к счастью она была выпущена в тот же день).

17. Необходима система анализа использования и репортов об ошибках, для удобства репорта ошибок при тестировании и анализа фидбека от клиентов/количества крашей на продакшене: TestFlight/FlightPath, GoogleAnalytics, Flurry, BugSense, Crashlytics (теперь часть Twitter Fabric), Crittercism, HockeyApp

Tricks

Общие:

1a. Часто возникают проблемы у пользователей с определенными девайсами или в определенных странах (например у Vodafone UK проблемы с WebP картинками). Для проверки такой экзотики можно использовать DeviceAnywhere (платный сервис), PerfectoMobile (платный сервис), Samsung Device Lab (бесплатно на некоторое время)

1b. Научитесть даунгрейдить прошивки - платформы фрагментированы, особенно Android и Blackberry. Облачные сервисы хороши, но стоят денег и не все компании имею достаточные денежные средства для оплаты.

2. Используйте цепочки кейсов “проблемы с сетью”, по максимуму используя роутер/проки/WANEm/Network Link Conditioner (MacOS, iOS)

3. Забивайте память девайса перед запуском приложения, тем самым:

• проводим стресс тестирование
• проверяем скорость работы
• проверяем куда вернемся после сворачивания приложения и стартанут ли апдейт-сервисы и тп.

4. Запускайте приложение в под дебаггером:

• есть шанс познать дзен :)
• позволяет работать медленно с приложением, что иногда вскрывает баги
• если в приложении случится краш или exception - оно остановится и можно будет подозвать разработчика отдебажить 'не отходят от кассы'

5. Научитесь вставлять логи в исходники вашего приложения.

6. Можно использовать dropbox если ваше приложение обновляет данные из xml/plist. Нам удавалось эмулировать целый сервер :)

7. Если нужен proxy-server - проще всего использовать CharlesProxy (есть мануал для iOS, Android девайсов и эмуляторов). 

8. Введите культуру 'pre-qa', когда разработчик завершил девелопмент фичи, но не отправил на равью. Вы просто садитесь с разработчиком за его машину и тестируете 5-10 минут фичу под дебаггером - большинство самых простых и глупых ошибок найдется сразу. Также позволяет научить разработчика базовым навыкам тестирования, как минимум он будет повторять за вами сам - никому не хочется допускать глупые ошибки :)

Android:

1. Выставьте кастомные разрешения экрана эмулятора – позволит выявить проблемы с layout, если у Вас есть определенная нехватка девайсов

2. Если клавиатура переопределена (используется кастомная) – уделите этому дополнительное внимание.

3. Используйте "обезьянку" Application/UI Monkey Exerciser. Статья в помощь :)

4. Staged rollout и бета-версии - Ваш лучший друг. Для удобства очень рекомендую использовать TestFairy (статья в помощь) - можно видеть графики загрузки девайсов и видео от бета-пользователей.

5. Используйте do not keep activities

iOS:

1. Проверьте, не переопределены ли стандартные жесты. Например, при активации “Универсального Доступа” – активируются дополнительные жесты, они могут конфликтовать с жестами Вашего приложения (например, трех- и четырехпальцевый жест)

2. Используйте "обезьянку" AntEater или UIAutoMonkey

3. Покажите разработчикам сервис rollout.io, который позволяет 'патчить' некоторые краши на продакшене, переопределять параметры, показывать алерты с извинениями или делать некоторые кнопки неактивными. Нас он уже спасал несколько раз

4. Бета-версии и TestFairy, опять же, Ваши лучшие друзья. Бета программу можно делать с помощью решений Apple, которые купили TestFlight, но к можалению, есть некоторые искусственные ограничения - 1000 пользователей, первое ревью бета-версии. Сервисы дистрибуции тоже можно использовать для бета-программы. Отличный обзор сервисов на хабре: 1, 2, 3, 4

5. Для интерактивного тестирования верстки или проверки что все скрины убрались из иерархии можно использовать стандартные средства Xcode или Spark Inspector/Reveal

Обсудить на форуме