[Test Plan] Visibility control of the fees
- Hellen Rodrigues Magalhaes
- 1 Introduction
- 1.1 Test Scope
- 1.1.1 In Scope
- 1.1.2 Out of Scope
- 1.2 Quality Objective
- 1.3 Test Methodology
- 1.4 Testing Tools
- 1.4.1 Testing Tools
- 1.4.2 Test Deliverables
- 1.5 Test Management
- 1.6 Test Actors
- 1.7 Launch Darkly
- 1.8 Whitelabel
- 1.1 Test Scope
Introduction
This document details how the Detailed payment error messages feature should be tested
Test Scope
In Scope
Application | Description |
|---|---|
Whitelabel | Whitelabel’s is where guests finish placing their orders, either it’s on mobile or the web. |
Launch Darkly | Feature management platform that allows development teams to control and manage feature flags to release software updates safely and continuously. |
Out of Scope
Application | Description |
|---|---|
POS |
Won’t be tested as this application won’t be changed by this feature's development |
Kiosk | |
Call Center |
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
Platform | Version | Description |
|---|---|---|
macOS | 15.0 |
|
Google Chrome | 126.0 |
|
Android Device | 14.0 |
|
iOS Device | 18.0 |
|
Insomnia | 9.3.0 | For backend tests |
Testing Subjects
Subject | Description |
|---|
Subject | Description |
|---|---|
Whitelabel | https://staging-plk-web.es.rbi.tools/ |
Test Deliverables
Test Plan (this document)
Test Cases
Bug Tasks
Test Management
Test Actors
User Role | Description |
|---|---|
User | User will be placing successful orders on Whitelabel |
Developer user | User responsible for enabling the FF on the Launch Darkly (LD) and setting which cards are accepted for each brand and country |
Launch Darkly
In order to perform the tests properly, It is essential that all feature flags in Launch Darkly are set properly.
FF | Rule | Value | Status |
|---|---|---|---|
- | - | FALSE | |
Region | ES, PT | TRUE | |
Country | ES, PT | TRUE | |
SanityDataSet | staging_bk_es staging_bk_pt staging_plk_es | TRUE | |
Country | PT | TRUE | |
Country | PT | TRUE | |
|
|
|
|
- | - | TRUE | |
- | - | TRUE | |
- | - | TRUE | |
- | - | TRUE | |
- | - | TRUE | |
- | - | FALSE | |
- | - | FALSE |
Whitelabel
It is possible to perform tests on the DEV environment, however, in this environment, there is neither real integration with delivery partner nor to POS. There is an exception in PLK ES, where there is a real integration to DMP (RBI), but the problem is that the DMP is a partner that is ready to receive the service fee info so far. So, to bring forward, you can test the scenarios by checking what is sent to the partner via Datadog, and when the feature is deployed on the staging environment you can test all the scenario checking directly on the partner's side.
Scenario 1: User sees only the Delivery Fee information on the cart page
Scenario 2: User sees only the Delivery Fee information on the receipts
Scenario 4: User sees only the Delivery Fee information being sent to the Delivery Partner - Homeria
Scenario 5: User sees only the Delivery Fee information being sent to the POS
Delivery Fee + Delivery Fee Discounts and Service Fee + Service Fee Discounts