Introduction

This document details how the Detailed payment error messages feature should be tested

Test Scope

In Scope

Out of Scope

Quality Objective

• Ensure that all Acceptance Criteria has been met.

• Ensure that all Test Cases has been executed and have passed.

• Ensure that all bugs found has been fixed and retested before the release.

Test Methodology

• Exploratory Testing

• Functional Testing

Testing Tools

Testing Tools

Testing Subjects

Test Deliverables

• Test Plan (this document)

• Test Cases

• Bug Tasks

Test Management

Test Actors

Whitelabel

General configs and pre-conditons:

Feature flags Intl Platform (backend):

• disable-paycomet-pre-auth: this FF need to be enabled with these configs:

• enable-rbi-error-2: this FF need to be enabled with these configs:

Test Part 1:

The test cases in part 1 should be performed in local environment because we are going to need the translations to be manipulated in each variation scenario and we also need to create mocks to simulate the errors coming from the backend. To do this:

1- Setup and run locally the Intl-whitelabel-graphql

• Mock the backend error:

Find this file: intl-whitelabel-graphql/src/functions/graphql/providers/payments.ts

Add the code below:

const ccc = '2';

errorPayload.code = `PAYMENT.${ccc}`;
errorPayload.rbiErrorCode = ccc;

When the const ccc = ''; here you can set the backend error that you want to simulate. E.g. 2.001, 2.100.001 and etc.

2-

1 to manipulate the content of the Lokalise existing on the local environment according to the pre-conditions for each test case:

• Scenario 1: [Split logic][Mapped errors][Title message] Validate the split logic on the title message when all the errors are mapped on the Lokalise

• Scenario 2: [Split logic][Non-mapped errors][Title message] Validate the split logic on the title message when some errors are NOT mapped on the Lokalise

• Scenario 3: [Split logic][Mapped errors][Message description] Validate the split logic on the message description when all the errors are mapped on the Lokalise

• Scenario 4: [Split logic][Non-mapped errors][Message description] Validate the split logic on the message description when some errors are NOT mapped on the Lokalise

• Scenario 5: [Split logic][Mapped errors][Modal button] Validate the split logic on the modal button when all the errors are mapped on the Lokalise

• Scenario 6: [Split logic][Non-mapped errors][Modal button] Validate the split logic on the modal button when some errors are NOT mapped on the Lokalise

Test Part 2:

We will be able to use Paycomet’s instruction to simulate some of the mapped errors. In this case, we need to use the CVV field and enter the code informed by Paycomet. The codes are availabe on this document.

If there is no code available to test, we will need to use a mock in order to simulate the errors.

• Scenario 7: [Mapped errors] Validate title error, modal description and modal button according to the mapped errors on the Lokalise

• Scenario 8: [Regression testing] Validate if the layout and responsive were kept on the existing error modal

• Scenario 9: [Regression testing] Validate if the button on the modal redirects the user to the cart page and the order is not placed

Analytics

Test Part 3:

• Scenario 10: [Analytics] Validate if the attributes were added on the existing modal appearance event

• Scenario 11: [Analytics] Validate if the attributes were removed on the existing modal appearance event

• Scenario 12: [Analytics] Validate if the attributes were removed on the existing modal appearance event