Сообщений в теме: 8

[Lyanna]

Здравствуйте, форумчане :) Форум просматриваю часто, пишу первый раз, извините, если что не правилам.

 

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

 

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

 

Очевидные случаи такие:

- совершить разовую покупку, проверить счет, проверить, что с карты списали нужную сумму

- оформить подписку, проверить, что ежемесячно приходят правильные счета и списывается нужная сумма

- отменить подписку, убедиться, что счета больше не приходят и с карты деньги не снимаются

- сделать вывод на пейпал

- как-то зафейлить платеж (неверные данные кредитки и т.п.), увидеть сообщение об ошибке

 

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

 

[Delf]

Добрый день :)
Подкину пару идей:
- фейл/восстановление покупки (обрыв коннекта/плохой коннект, таймаут): случай когда деньги спишет, но валидацию не пройдет (здесь можно обложиться кейсами :)
- привязать 1 карту на 2 аккаунта и перебрать случаи с подписками и покупками (люди разные бывают)
- привязка нескольких карт к аккаунту? :)
+ все моменты с привязкой карт, оплатой (отмены платежей?), подписками/отказом от них - должны быть очевидными для пользователя (есть плохие примеры сервисов, где можно днями разбираться в этих вещах... в итоге плюнуть и перестать ими пользоваться)

Как-то вот так, что в голову сразу в дороге пришло :)

[BadMF]

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

[ryjii]

Скажу одно слово: безопасность.

[Dalay_LAMO]

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

 

+1
"Сторонняя платежная система", которая у вас используется, наверняка предоставляла документацию по API. Соответственно, эту документацию можно изучить. Правда, есть шанс в ней ничего не понять, тогда остаётся путь - теребить разработчика-исполнителя и просить, чтобы он доступно объяснил, как всё это дело реализовано. И после понимания зон ответственности уже можно продумывать план тестирования.

[Юльчик]

Я бы добавила еще несколько покупок и отсутствие достаточной суммы на счету (особенно актуально, если хватает на одну покупку, но не хватает на 2). Кроме того, смоделировала бы параллельную работу - ну типа покупки одного товара двумя покупателями или снятие с продажи в момент оформления покупки.

Стороннюю платежную систему вы не тестируете, сосредоточьтесь на своей части и выдаваемых формах (возможностях возврата по страницам, изменения информации).

[SHINNOK]

Самые главные вещи здесь безопасность и функционал.

Функционал сперва тестируете по позитивным сценариям, а затем по негативным. В позитивных сценариях пинайте разработчика, чтобы он вам объяснил, что и как работает, и читайте документацию (Если она, конечно, есть)

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

Безопасность - как шифруются данные со стороны сервера, поддерживают ли такой уровень клиенты/браузеры, возможны ли SQL, PHP-инъекции и межсайтовый скриптинг, возможно ли прослушать траффик и подменить куки, и т.д.

[Lyanna]

Большое всем спасибо, появились новые идеи! :) Дополню: вопрос о тестировании безопасности не стоит (точнее, я подниму этот вопрос, но изначально речь велась только о функционале), ну и так как используется сторонняя система, то считаем, что ее протестировали ее же тестировщики :)

 

АПИ от платежной системы, конечно, есть, документации по проекту правда никакой, но разработчики доступны, и позитивные сценарии с ними можно проработать без проблем. Главное не упустить негатив.

[Daffodil]

Добрый день всем!

 

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

 

1) Насколько глубоким должно быть тестирование?

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

I. Я удаляю карту.

II. В назначенный день происходит оплата (деньги снимаются с карты пользователя и зачисляются на карту продавца).

III. В ЛК пользователя появлется новый лицензионный ключ.

Не является ли проверка того, появляется ли новый лицензионный ключ после удаления данных о карте, избыточной?

 

2) Нужно ли тестировать одновременно в клиентской и серверной части?

Например, пользователь решил поменять своё имя. Теоретически это можно проверить двумя способами - посмотреть, изменилось ли его имя в ЛК, и посмотреть, изменилось ли оно в базе данных. Но опять-таки, не будет ли это избыточным тестированием?