Комментарии 8
Привет! Основные трудности, при тестировании раздела оплат:
1. Доступы, лучше заранее озаботиться нужными пермишнами и учетками, чтобы потом не тратить на это свое время и деньги компании
2. Нюансы налогообложения: например, есть экономические зоны, где НДС на товары не распространяется. А в соседней республике / штате НДС уже действует
3. Валюта и ее конвертация. Если у вас международный проект, то стоит учитывать правила конвертации валют внутри вашей компании
4. Платежные системы: мастеркард, виза, мир, сбп и многие другие. Какие-то могут быть доступны, какие-то нет
5. Сохранение данных об оплате: данные карты и пользователя. Важно учитывать доступность удаления этих данных.
С ходу всего не вспомнить, но нюансов тут много, сильно зависит от продукта.
Специфика продукта действительно может влиять на процесс тестирования. Например, подписочная система оплат, сильно отличается от единовременной оплаты за товары и услуги. Других моментов по специфике не могу выделить. Как правило, все такие моменты регулируются законами той страны, в которой продаются товары и услуги и надо учитывать не специфику самих продуктов, а специфику законов :)
Хотелось бы от всей души поблагодарить автора за прекрасную статью и затраченные на нее силы. Весьма полезная и толковая статья, которая обязательно найдет отклик в умах своих читателей.
Ну а теперь перехожу непосредственно к своему развернутому комментарию.
Сильные стороны:
Практическая направленность: Автор статьи делится своим опытом применения техник тест-дизайна в реальном проекте, что делает материал более интересным и ценным для читателей, особенно для тех, кто только начинает свой путь в тестировании. Также стоит отметить, что автор уделяет внимание не только техникам тестирования, но и важности декомпозиции системы перед началом тестирования. Он подробно описывает, как он разбивает систему оплаты на отдельные компоненты и как это помогает ему более эффективно проводить тестирование.
Четкость и структурированность: Статья хорошо структурирована, содержит понятные определения и примеры, что облегчает восприятие информации.
Комплексный подход: Автор статьи не ограничивается описанием одной техники тест-дизайна, а рассматривает их комбинацию, что позволяет провести более полное тестирование системы.
Наглядность: Иллюстрации и схемы, используемые в статье, помогают лучше понять описываемые концепции.
Актуальность: Тема статьи актуальна для QA-специалистов, занимающихся тестированием систем оплаты.
Точки роста:
Недостаточно подробное описание некоторых техник: Автор статьи мог бы более подробно описать некоторые техники тест-дизайна, например, прогнозирование ошибок.
Не уделено достаточное внимания различным типам ошибок, которые могут возникнуть при тестировании систем оплаты. Он упоминает о "потере свойства оплаты", но не рассматривает другие возможные ошибки, такие как неправильное округление сумм, проблемы с обработкой возвратов и т.д.
Не упоминается о важности тестирования безопасности системы оплаты. В современном мире это является одним из ключевых аспектов тестирования, так как системы оплаты часто становятся целью для хакерских атак.
Отсутствие примеров тестовых сценариев: Примеры тестовых сценариев, основанных на описанных техниках, могли бы сделать статью еще более практичной.
Недостаточная фокусировка на нюансах: Автор статьи мог бы более подробно остановиться на нюансах тестирования систем оплаты, связанных с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Рекомендации:
Добавить больше примеров тестовых сценариев.
Более подробно описать прогнозирование ошибок.
Рассмотреть нюансы тестирования систем оплаты, связанные с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Общее впечатление:
Статья "Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты" является ценным ресурсом для QA-специалистов, занимающихся тестированием систем оплаты. Автор статьи делится своим опытом применения техник тест-дизайна, что делает материал интересным и практичным.
Моя оценка: 4,5 из 5.
Дополнительные комментарии:
Автор статьи мог бы добавить раздел "Заключение", в котором он бы подвел итоги и дал рекомендации по применению описанных техник тест-дизайна.
В статье можно было бы использовать больше ссылок на дополнительные ресурсы по теме тестирования систем оплаты.
В целом, статья представляет собой полезный обзор техник тестирования систем оплаты и может быть интересна как начинающим, так и опытным тестировщикам. Она подчеркивает важность комбинирования различных техник и подхода к тестированию с разных сторон.
Схема очень упрощенная. Оплаты тестировать - дело куда серьезнее.
Кроме возвратов, есть еще реверсалы, ручные и автоматические, когда при оплате что-то пошло не так, а пойти не так может что-угодно: эмитент не одобрил, денег не хватило, фрод, эквайер не поддерживает карты, которой пытаются платить, сбой технический на стороне магазина, на стороне процессинга и т.д. И т.п.
Искала по тексту про банки, но есть только платежные системы. А ведь на самом деле при оплате картой, где бы то ни было, онлайн/офлайн, цепочка несколько сложнее. Магазин/система оплаты не взаимодействуют с платежными системами напрямую. Данные о транзакции обрабатывает банк-эквайер, запрашивая разрешение на операцию у банка-эмитента, если все ок, деньги блокируются на карте/счете, эквайер отправляет данные в платежную систему и после обработки платежной системой, сведения идут эмитенту, те снимают блокировку и списывают, наконец, деньги с клиента. Так происходит клиринг.
Т.е. ошибок на пути оплаты может быть гораздо, гораздо больше на всех уровнях. И до проведения клирингов считать, что операция успешная нет смысла. И если операция потерялась, то внутренними силами это решить почти нереально, только при участии банков.
Да, действительно, схема упрощённая, т.к. я пытался сыграть в "универсальность применения" и не нарушить NDA нашей компании.
Про реверсалы Вы хорошо подметили, я это забыл упомянуть. Я не так часто сталкивался с какими-то проблемами и нюансами в их работе. Зачастую проблемы с ними возникают со стороны клиента или банка. Это только мой опыт, возможно у Вас на проекте по другому.
Про банки тоже хорошо подметили, но в статье я больше делаю упор на тестировании оплат со стороны магазина, а не банка. Проблемы возникающие между эмитентом и эквайером, как правило, не являются проблемами магазина. Возможно Вы меня поправите.
И да, ошибок сильно больше. И действительно, тестирование оплат и поиск причин ошибок, это действия тесно завязанные на интеграции между магазинами, банками, платежными системами и прочим. Вряд ли получится учесть все нюансы, но базу для тестирования я вижу так, как описал в статье. Плюсом надо помнить, что не всегда у тестировщика на проекте есть доступы ко всему. Многое от наших глаз закрыто по разным соображениям. Поэтому плаваем и варимся в том, что есть :)
Спасибо за Ваш комментарий!
Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты