Test Strategy

Cost Management
Reviewers:
This document must be reviewed by the following:

Name Signature Title / Responsibility Date Version

Subbarao Nadendla Architect/Technical Lead 9-5-2023 1.0

Chet Mehta Product Owner 9-5-2023 1.0

Ruaridh Hutchison Lead Architect 23-5-2023 1.0

Approvals:
This document must be approved by the following:

Name Signature Title / Responsibility Date Version

1. Introduction
The CMM project will build a Cost Management product which will be the system of record for marine costs
and will digitize and simplify the current processes, allowing better management of costs across the
transaction lifecycle in the Refining and Product Trading (RPT) domain of Trading and Shipping.

Currently, processing of ancillary costs are manually intensive and lack standardized processes across RPT.
As these processes are highly manual and lack standardization, there is a significant opportunity to improve
efficiency and enhance the ability to better manage commercially.

The scope of CMM will be the nomination of service providers, raising provisions to account for costs
nominated but not yet billed, and then automated invoice and provision management. By nomination activity
taking place through CMM, there will also be a preventative control introduce to ensure service providers are
cleared through the counterparty due diligence processes.

Enabling transparency of ancillary costs and improving RPT’s ability to increase RCOP by reducing marine
costs. Automating decisions and processes within an integrated single source of transactions and eliminating
rework end to end to deliver cost savings.

The solution expects to reduce operational risk through creation of enhanced preventative controls by
integration with the counterparty due diligence (CDD)system to mitigate the risk of a CDD breach.
This will reduce operational risk and risk to license to operate for the RPT marine business. Further, the
solution will reduce duplicate payment risk which historically has resulted in 6 recorded events in COLT.

1.1 Purpose
The purpose of this Test Strategy is to define the overall approach that will be taken by the Test Team when
delivering testing services.

The document helps to clarify the testing activities, roles and responsibilities, processes, and practice to be
used.

2. Approach
• All testing tasks will be conducted in line with the Software Test Life Cycle (STLC) and in support of
the Software Development Life Cycle (SDLC). The documents used within the SDLC will be
completed both by the Test Team and the project participants that are responsible for providing
information and deliverables to the Test Team.

• Create quality test data (production like).

• Focus on progressive automation to automate newly developed features within current sprint.

• Target to achieve 100% test coverage using automation

3. Test Entrance Criteria

Entrance criteria are the required conditions and standards for work product quality that must be present or
met prior to the start of a test phase.
Entrance criteria shall include following:
• Review of completed test script(s) for the prior test phase.
• No open critical/major defects remaining from the prior test phase.
• Sanity and Unit tests have been completed successfully to demonstrate readiness for test
• Correct versioning of components moved into the appropriate test environment.
 • Testing environment is configured and ready.

4. Test Exit Criteria

Exit criteria are the required conditions and standards for work product quality that block the promotion of
incomplete or defective work products to the next test phase of the component.
Exit criteria shall include the following:
• Successful execution of the test scripts(s) for the current test phase.
• No open critical, major, or average severity defects unless the issue is determined to be low
impact and low risk.
• Component stability in the appropriate test environment.

5. Test Pyramid illustrating types of tests

E2E tests

UI tests

Integration Tests

API tests

Unit tests

Types of tests
1. Unit Tests-unit tests are written by developers to cover the smallest testable units of the program.
Junit
2. API Tests- focuses on the business requirements of application. Scenarios to be written in Gherkin
language. JVM Cucumber framework to be used. Other libraries to be used are Rest libraries etc.
3. Integration Tests- focus is on verifying that different modules or services used by our application work
well together. Scenarios to be written in Gherkin language. JVM Cucumber framework to be used.
4. UI Tests- This covers testing of user actions performed on react web application. Playwrite can be
used as testing tool to create these tests
5. E2E tests- replicates a user behavior with the software in a complete application environment. It
verifies that various user flows work as expected.
6.Roles and responsibility
Unit tests API tests Integration tests UI tests E2E tests

Responsible Developer SDET, developer SDET SDET, SDET, BA

developer

Reviewer Developer SDET, Developer, SDET, BA SDET, SDET, BA

BA developer,
BA

CI/CD build, run deploy to dev/test, deploy to deploy to Manual

tests, deploy run tests dev/test, run tests dev/test, run
to dev/test tests

7. Test environments
1. Dev environment-developers to use this environment for dev and test
2. Test environment- testing team to use this environment for their system testing and regression testing
3. Integration environment- testing team, BAs to use this environment to perform integration testing
4. UAT environment- Can be used as demo environment to users, users to perform testing to confirm
the expected behavior

8. Defect management
• Defects to be logged in ADO
• Defects to be raised as and when found while testing
• defects found in a feature while testing within sprint to be raised as task and assign the PBI back
to dev
• Defects found in later stages of testing to be raised as bug in ADO
• Defects triage to be held once or twice a week
9. Risks and Contingencies

Risk Mitigation Strategy Impact

Product Management and Development to

Delays in delivering completed Test Items
advise of any delays and adjust Release
1 from Development would impact test High
Scope of Resources to allow the test activities
timescales and final Release quality
to be performed.
Delays in the turnaround time for fixing Strong management of bug resolution would
critical bugs, which would require re- be required from Development to ensure bugs
2
testing, could have an impact on the are fixed and available for re-testing in the High
project dates. scheduled time.
The Test Team, Development or PM
The Test Team, Development and PM teams
teams require domain guidance from one
3 to ensure they are available at critical points Medium
or the other and they are not available.
or contactable during the project activities.
This would delay project activities.
The Test Team will record untested features
Low
4 Some features/items may not be testable. and request the PM to assess business risk in
support of the release of untested features.
Unexpected dependencies between Test
Information about dependencies is updated
Items and service components are
5 and communicated promptly to allow timely Low
encountered that require revision of Test
revision of Test Scenarios and Test Cases
Scenarios and related Test Cases.