Disclaimer. Этот пост написан на основе доклада на SQADays’15. Вы можете также посмотреть видео выступления или полистать презентацию. Обращаю внимание, что доклад был начального уровня, то есть пост будет интересен в основном менеджерам и начинающим тестировщикам. А также на то, что автор — ненастоящий сварщик и местами делает довольно грубые округления.
Меня зовут Алёна, и я релиз-менеджер. Отдел компании i-Free, в котором я работаю, в основном занимается приложениями под iOS и Android. Ещё мы поддерживаем Tizen, Windows Phone, альтернативные сторы, но в данном посте речь пойдёт об Apple iOS Appstore и Google Play.
В обоих маркетах, помимо платных и бесплатных приложений, есть возможность проводить внутренние платежи — ин-аппы (In-App Purchases).
Почему я рассказываю про тестирование ин-аппов? Потому что могу!
Будучи релиз-менеджером, я участвую в проектах обычно в начале разработки и в конце тех итераций, которые заканчиваются выкладкой в сторы. Перед началом проекта выдаю разработчикам ключи и сертификаты, а к концу работы над версией разработчики отдают мне билды для релиза. Но между этими точками есть момент, когда надо завести внутренние платежи — ин-аппы и выдать тестировщикам тестовые аккаунты. И вот на этом этапе иногда случается что-то странное, когда разработчики считают, что у них всё хорошо, а тестировщики — что всё плохо.
Для начала, напомню вкратце о том, как проходят платежи в мобильных приложениях и что нужно для их тестирования.
Итак, в том или ином виде в обоих маркетах есть:
Стандартная схема покупки ин-аппов в мобильных сторах:
Пункты 3 и 4 актуальны только для многоразовых покупок — должны быть, но так происходит не всегда. Подробности будут ниже.
Начнём с того, что в случае Google Play мы имеем дело с полупесочницей. Мы будем использовать реальные аккаунты, которые отмечены в девелоперском аккаунте как «тестовые». При этом к аккаунту должна быть привязана банковская карта, но фактически списаний с неё не будет. Ну и благодаря открытости самой платформы, мы имеем полноценные логи и простую установку билдов.
Итак, что нужно:
При нажатии на ин-апп мы видим окно с подписью «это тестовый платёж». Покупка проходит почти мгновенно и завершается успешно, деньги с карты не списываются.
В приложении нам начисляются положенные блага
Тестировать платежи можно только на билде той же версии, что и в админке. Но с тех пор, как введено тестирование не с помощью черновиков билда, а через бета-тест, эта ошибка должна встречаться гораздо реже.
Что делать:
Если фактически с интернетом всё хорошо, практически всегда лечится переключением с 3g на wi-fi или с wi-fi на другой wi-fi.
Обещанное отступление. Во многих маркетах есть различие между одноразовыми и многоразовыми ин-аппами. В Google Play оно тоже было, но с февраля 2013 был введён биллинг версии 3. С тех пор ин-аппы бывают “управляемые Google” и “управляемые разработчиком”, а можно ли их купить несколько раз — зависит от того, как разработчик их обрабатывает (консьюмит или нет).
На самом деле пользователь никогда не должен видеть эту ошибку. Если же это происходит, либо разработчик обращается к одноразовым ин-аппам как к многоразовым, либо Google закрутил покупку между Google Checkout и Google Play, надо подождать пару часов и/или перезагрузиться.
Обычно это проблема покупателей из-за неверно настроенного Google Checkout.
Что делать:
Или Google сказал, что платёж прошёл успешно, а приложение сказало, что нет.
Важно понимать, что в данном случае проблема на стороне приложения. То есть если Google ответил, что платёж прошёл успешно — он всегда однозначно посылает именно такой ответ. Но приложение должно ещё суметь его обработать!
Ещё можно запомнить слова license key. Дело в том, что небольшая строка цифр и букв, которая удостоверяет ин-аппы, платные приложения и докачку дополнительного контента, сейчас уникальна для каждого приложения. И если вы по каким-то причинам делаете две версии приложения (на русский и международный рынок, или платную и бесплатную версии, например), есть вероятность, что кто-то где-то забудет поменять эту строчку. Вовремя произнесённые слова “а у нас всё в порядке с лицензионным ключом?” могут сэкономить несколько хлопков одной ладонью по лбу.
А вот у Apple нас ожидает полноценная песочница. Но значит ли это, что нам будет легче?
Итак, никаких реальных карточек и реальных аккаунтов. При этом тестовый аккаунт привязывается к стору определённой страны, это важно. Ещё не нужно никуда в админку заливать билды, так что за исключением выдачи тестовых аккаунтов эта часть проходит без моего участия.
Но всё не так просто — провижены! Грубо говоря, это списки, в которых перечисляется, какие разработчики имеют право собирать приложение с определённым идентификатором, и на какие девайсы можно ставить получившийся билд.
Ну и две админки — Tunes Connect для промо-материалов, Member Center для разработчиков.
При нажатии на ин-апп появляется окно с подписью [Enviroment: Sandbox].
Это полностью несуществующий аккаунт, но e-mail должен быть уникальным среди как тестовых, так и реальных акаунтов. У него не нужно вводить информацию о кредитной карте, а дата рождения вводится один раз при создании в админке. Если тестовый аккаунт на устройстве просит ввести что- то, кроме логина и пароля – вы его сломали. Совсем. Надо делать новый.
Если на такой табличке нажать кнопку “продолжить”, вас попросят ввести информацию о платёжном средстве. Это значит, что вы неправильно привязали тестовый аккаунт. Он может быть привязан к устройству лишь одним способом:
Все остальные способы не сработают и сломают аккаунт, придётся делать новый.
Тоже связанная с аккаунтом ошибка. Что это может значить:
Очень странная ошибка, такого ограничения нет. Но вы можете встретить похожую при упорном тестировании подписок. Лично не встречала, единственный совет — будьте осторожны при тестировании iOS-подписок :)
Может появиться на устройстве с jailbreak или при крайне плохом соединении с интернетом. Лично не встречала, совет — по возможности не тестируйте на устройствах с jailbreak. Если, конечно, это не часть вашей целевой аудитории.
Доклад был прочитан 18 апреля, с тех пор ситуация изменилась не сильно, за исключением способа выкладки билдов в Google Play для тестирования. Раньше было достаточно просто завести билд как черновик, теперь же надо опубликовать в бета-тест, что, с одной стороны, увеличивает количество необходимых материалов на этой стадии (надо сразу иметь иконку, скриншоты и описание), но с другой — облегчает обновление билда тем, кто является заинтересованной стороной в разработке, но при этом не углубляется в тестирование. Например, ПМ или дизайнеры, они просто получают пуш «новая версия» как от обычного приложения.
Если вы встречали какие-то иные ошибки самого стора при осуществлении внутренних платежей — будет интересно прочитать о них в комментариях.
Меня зовут Алёна, и я релиз-менеджер. Отдел компании i-Free, в котором я работаю, в основном занимается приложениями под iOS и Android. Ещё мы поддерживаем Tizen, Windows Phone, альтернативные сторы, но в данном посте речь пойдёт об Apple iOS Appstore и Google Play.
В обоих маркетах, помимо платных и бесплатных приложений, есть возможность проводить внутренние платежи — ин-аппы (In-App Purchases).
Почему я рассказываю про тестирование ин-аппов? Потому что могу!
Будучи релиз-менеджером, я участвую в проектах обычно в начале разработки и в конце тех итераций, которые заканчиваются выкладкой в сторы. Перед началом проекта выдаю разработчикам ключи и сертификаты, а к концу работы над версией разработчики отдают мне билды для релиза. Но между этими точками есть момент, когда надо завести внутренние платежи — ин-аппы и выдать тестировщикам тестовые аккаунты. И вот на этом этапе иногда случается что-то странное, когда разработчики считают, что у них всё хорошо, а тестировщики — что всё плохо.
Общая информация про тестирование ин-аппов
Для начала, напомню вкратце о том, как проходят платежи в мобильных приложениях и что нужно для их тестирования.
Итак, в том или ином виде в обоих маркетах есть:
- Песочница для тестирования платежей
- Механизм тестовых аккаунтов, чтобы не тратить деньги
- Тестовые билды и тестовые девайсы
Стандартная схема покупки ин-аппов в мобильных сторах:
- Сначала пользователь жмёт на кнопочку «купить» и вводит пароль. Проходит сама покупка, работают механизмы площадки
- Информация о покупке передаётся в приложение
- Потребление купленного ин-аппа (consume)
- Ин-апп становится доступным для повторного приобретения
Пункты 3 и 4 актуальны только для многоразовых покупок — должны быть, но так происходит не всегда. Подробности будут ниже.
Специфика тестирования Google Play In-App Purchases
Как тестировать и что для этого нужно
Начнём с того, что в случае Google Play мы имеем дело с полупесочницей. Мы будем использовать реальные аккаунты, которые отмечены в девелоперском аккаунте как «тестовые». При этом к аккаунту должна быть привязана банковская карта, но фактически списаний с неё не будет. Ну и благодаря открытости самой платформы, мы имеем полноценные логи и простую установку билдов.
Итак, что нужно:
- Девелоперский аккаунт с объявленными в нём тестовыми аккаунтами
- Тестовый аккаунт с привязанной к нему карточкой и участвующий в бета-тесте
- Опубликованный в бета-тест билд приложения
- Тестовое устройство, залогиненное в тестовый аккаунт. На него скачиваем билд из бета-теста.
Как выглядит, когда всё хорошо:
При нажатии на ин-апп мы видим окно с подписью «это тестовый платёж». Покупка проходит почти мгновенно и завершается успешно, деньги с карты не списываются.
В приложении нам начисляются положенные блага
Что может быть, когда всё плохо?
Ошибка -№1 несоответствие версии билда
Тестировать платежи можно только на билде той же версии, что и в админке. Но с тех пор, как введено тестирование не с помощью черновиков билда, а через бета-тест, эта ошибка должна встречаться гораздо реже.
Что делать:
- проверить совпадение версий на устройстве и в админке
- подождать — только что загруженная версия может быть не видна приложению часа два-четыре.
Ошибка №2 — плохое соединение:
Если фактически с интернетом всё хорошо, практически всегда лечится переключением с 3g на wi-fi или с wi-fi на другой wi-fi.
Ошибка №3 — купить купленное:
Обещанное отступление. Во многих маркетах есть различие между одноразовыми и многоразовыми ин-аппами. В Google Play оно тоже было, но с февраля 2013 был введён биллинг версии 3. С тех пор ин-аппы бывают “управляемые Google” и “управляемые разработчиком”, а можно ли их купить несколько раз — зависит от того, как разработчик их обрабатывает (консьюмит или нет).
На самом деле пользователь никогда не должен видеть эту ошибку. Если же это происходит, либо разработчик обращается к одноразовым ин-аппам как к многоразовым, либо Google закрутил покупку между Google Checkout и Google Play, надо подождать пару часов и/или перезагрузиться.
Ошибка №4 — [буквы и цифры в квадратных скобках]
Обычно это проблема покупателей из-за неверно настроенного Google Checkout.
Что делать:
- стандартные ритуалы: перезагрузиться и подождать немного
- крайняя мера – очистить данные Google Services
Вроде бы всё хорошо, но ин-апп не начислился
Или Google сказал, что платёж прошёл успешно, а приложение сказало, что нет.
Важно понимать, что в данном случае проблема на стороне приложения. То есть если Google ответил, что платёж прошёл успешно — он всегда однозначно посылает именно такой ответ. Но приложение должно ещё суметь его обработать!
- Что делать? Подождать, пока программисты починят
- Это критикал, такие ин-аппы пропадают бесследно!
- Скорее всего, это серверная ошибка, связанная с подписью
Ещё можно запомнить слова license key. Дело в том, что небольшая строка цифр и букв, которая удостоверяет ин-аппы, платные приложения и докачку дополнительного контента, сейчас уникальна для каждого приложения. И если вы по каким-то причинам делаете две версии приложения (на русский и международный рынок, или платную и бесплатную версии, например), есть вероятность, что кто-то где-то забудет поменять эту строчку. Вовремя произнесённые слова “а у нас всё в порядке с лицензионным ключом?” могут сэкономить несколько хлопков одной ладонью по лбу.
Специфика тестирования iOS
Как тестировать
А вот у Apple нас ожидает полноценная песочница. Но значит ли это, что нам будет легче?
Итак, никаких реальных карточек и реальных аккаунтов. При этом тестовый аккаунт привязывается к стору определённой страны, это важно. Ещё не нужно никуда в админку заливать билды, так что за исключением выдачи тестовых аккаунтов эта часть проходит без моего участия.
Но всё не так просто — провижены! Грубо говоря, это списки, в которых перечисляется, какие разработчики имеют право собирать приложение с определённым идентификатором, и на какие девайсы можно ставить получившийся билд.
Ну и две админки — Tunes Connect для промо-материалов, Member Center для разработчиков.
Что нужно для тестирования:
- «Cкелет» приложения в iTunes Connect, только после этого можно завести ин-аппы
- Тестовый аккаунт страны, на которую заведено приложение
- Тестовый девайс, заведённый в Member Center
- Правильно собранный билд, установленный на правильный девайс
Что происходит, когда всё хорошо:
При нажатии на ин-апп появляется окно с подписью [Enviroment: Sandbox].
Что делать, когда что-то не так?
Прежде всего — важная информация о тестовых аккаунтах iOS
Это полностью несуществующий аккаунт, но e-mail должен быть уникальным среди как тестовых, так и реальных акаунтов. У него не нужно вводить информацию о кредитной карте, а дата рождения вводится один раз при создании в админке. Если тестовый аккаунт на устройстве просит ввести что- то, кроме логина и пароля – вы его сломали. Совсем. Надо делать новый.
Ошибка №1 — вам нужно ввести платёжную информацию
Если на такой табличке нажать кнопку “продолжить”, вас попросят ввести информацию о платёжном средстве. Это значит, что вы неправильно привязали тестовый аккаунт. Он может быть привязан к устройству лишь одним способом:
- Надо отвязать от устройства все настоящие аккаунты
- Зайти в приложение
- Тапнуть на ин-апп
- И ввести логин-пароль
Все остальные способы не сработают и сломают аккаунт, придётся делать новый.
Ошибка №2 — вы не можете совершить эту покупку
Тоже связанная с аккаунтом ошибка. Что это может значить:
- Заведённое приложение недоступно в стране тестового аккаунта
- Приложение и тестовый аккаунт принадлежат разным девелоперским аккаунтам
- Вы используете реальный аккаунт
Ошибка №3 — ограничение на количество покупок
Очень странная ошибка, такого ограничения нет. Но вы можете встретить похожую при упорном тестировании подписок. Лично не встречала, единственный совет — будьте осторожны при тестировании iOS-подписок :)
Ошибка №4 — да вы же не тестовый пользователь!
Может появиться на устройстве с jailbreak или при крайне плохом соединении с интернетом. Лично не встречала, совет — по возможности не тестируйте на устройствах с jailbreak. Если, конечно, это не часть вашей целевой аудитории.
Доклад был прочитан 18 апреля, с тех пор ситуация изменилась не сильно, за исключением способа выкладки билдов в Google Play для тестирования. Раньше было достаточно просто завести билд как черновик, теперь же надо опубликовать в бета-тест, что, с одной стороны, увеличивает количество необходимых материалов на этой стадии (надо сразу иметь иконку, скриншоты и описание), но с другой — облегчает обновление билда тем, кто является заинтересованной стороной в разработке, но при этом не углубляется в тестирование. Например, ПМ или дизайнеры, они просто получают пуш «новая версия» как от обычного приложения.
Если вы встречали какие-то иные ошибки самого стора при осуществлении внутренних платежей — будет интересно прочитать о них в комментариях.
