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