UAT Policy

Version: 9, effective date: 09-Oct-2023

Olga Ovchinnikova

---

Contents

• 1 Standard description

• 2 Document objectives and benefits

  • 2.1 Objectives

• 3 Definitions

• 4 Roles & Responsibilities

• 5 Introduction

  • 5.1 Necessity of UAT
  • 5.2 Benefits of UAT
  • 5.3 Actors
  • 5.4 When to start UAT
  • 5.5 Where does UAT stand in testing strategy?
  • 5.6 UAT execution approaches
    • 5.6.1 GSC CP only
    • 5.6.2 Hybrid (GSC CP & BTS & GDC TTDC QA Team)
    • 5.6.3 QA Team only

• 6 UAT Processes

  • 6.1 Acceptance criteria definition
  • 6.2 UAT approach decision and UAT team formation
  • 6.3 UAT test plan
  • 6.4 UAT preparations
  • 6.5 UAT environment configurations
  • 6.6 UAT execution
  • 6.7 UAT closure
  • 6.8 ITSP process flow
  • 6.9 ARCI matrix

• 7 Standard Owner

• 8 Document control

  • 8.1 Contact person
  • 8.2 Document review
  • 8.3 Revision History

• 9 References

1 Standard description

This document describes how the User Acceptance Testing (UAT) processes will be embraced by T&T(Track and Trace) Quality Assurance Standards and followed up in future projects.

2 Document objectives and benefits

2.1 Objectives

Objectives of the document are:

• Description of the necessity of UAT

• Description of UAT processes and their types

• Defining the involvement of QA in UAT

• UAT team responsible and their responsibilities

3 Definitions

Abbreviation / Term	Explanation
STLC	Software Testing Life Cycle
ITSP	Information Technology Service Portal(Product of JTI)
UAT	User Acceptance Testing
QA	Quality Assurance
CHG	ITSP Change Request
FRS	Functional Requirement Specification
API	Application Programming Interface

Please refer to IT Glossary in the IT P&P portal for further definitions.

4 Roles & Responsibilities

Accountable: Approves the activity or recommendations from a person or team.

Responsible: Responsible for doing the work associated with an activity, either by completing personally or through sole accountability for a team’s output.

Consulted: Reviews the output of an activity and provides input but has no approval authority. Provides support to activity and may be consulted by the team during the course of the activity.

Informed: Is informed about activities to aid in planning own work.

#	Activity	GDC TTDC	BTS T&T	GSC CP
1	Define and maintain standard	R	A	C
2	Apply the standard in the T&T process	R	A/R	R

5 Introduction

5.1 Necessity of UAT

User Acceptance Testing (UAT) is a type of software testing performed by users as a final functional testing phase. This test aims to ensure that the software meets the business requirements. End users or power users, who are familiar with the business needs, performs this test phase.

In general, functional testing is carried out by technical staff (Developers and QA engineers). As a result, requirements are being examined from a technical point of view.

Developers and QA engineers may not have the business perspective in mind while conducting their part of testing hence why a UAT team must be formed to take on this testing activity, consisting of people who have the business foresight.

The required changes can be evaluated from a business standpoint where the UAT team might foresee some business implications before production. UAT is critical in ensuring that business needs are met before releasing the product. Because of the utilization of live data and real-world usage scenarios, this testing is a crucial aspect of the production schedule. It is essentially the last main phase before the product goes live.

UAT is a critical milestone since the ownership of the current step of the process is changing: the requestor takes it over from IT to validate that deliverables meet requirements.

1. Validation is made against stated and aligned acceptance criteria.

2. Validation is fulfilled by executing previously created test scenarios, supporting each acceptance criteria.

3. Deliverables must successfully pass all acceptance criteria before being put into production.

5.2 Benefits of UAT

• Reduces the overall expense of upkeep.

• Helps to find bugs and identify any logical concerns in business flow as quickly as possible.

• Share the perspective of the final consumer.

• Gives a chance for final customer to experience the product before release.

• Optimizes the experience for the final consumer.

5.3 Actors

Role name	JTI team	Main responsibility
Requestor(s)	GSC CP/end-user*	The requestor is business representative who is requesting a change(UAT kick-off)
Assignment member(s)	BTS/GDC TTDC	Assignment member is a person who is in charge of the change(UAT kick-off) from IT side
QA Team	GDC TTDC QA	Assist all teams in UAT process with knowledge gained from previous test executions of the system
UAT Team**	Requestor/Delegated by Requestor*	Write test cases, execute test cases, follow up on bug/defects during UAT phase

* Usually, GSC CP creates the related ITSP request on behalf of the end user. ** UAT team should be formed by the Requestor before the UAT process can begin. UAT team consists of whoever will use the product when it is released and/or people who have extended business knowledge of where the IT product will be used.

5.4 When to start UAT

UAT is the latest stage of QA testing, in which:

• All test suites are performed by the QA Team.

• Product is in a state of which it fulfils all requirements mentioned in the FRS document.

• No other than minor defects remain in the system and rest are fixed by the Development team.

• Technical assessment of the application shows that it is ready for production deployment.

Preparation for UAT should start with finalizing the requirements. Acceptance criteria is a deliverable of the requirement preparation phase, and these criteria should serve as the basis for UAT scenarios description. Responsible individuals for UAT should start preparing UAT test cases right after the Acceptance criteria finalization.

5.5 Where does UAT stand in testing strategy?

The following schema shows activities that take place in the IT testing strategy and represents the position of UAT in overall testing. Each activity has a responsible actor shown on the schema.

5.6 UAT execution approaches

During UAT planning, the Requestor and Assignment member decide with QA Team which UAT Execution Approach will be used and apply it to CHG, mentioning, for example, “QA supported UAT will be performed”.

It must be noted that it should be agreed upon who will execute the UAT phase, this agreement process must involve representatives of GSC CP(requestor(s)), BTS(assignment member(s)) and QA team to pick the best approach. UAT team is the main responsible party in all aspects of the UAT phase of testing while all other involved in this phase is obliged to assist the UAT team.

How to choose UAT execution approach:

5.6.1 GSC CP only

• During the UAT stage, QA Team or any other party is not involved in test execution.
• UAT Team consists of the GSC CP users, end-users, and power users only. Therefore, completely independent test execution will be held.

This approach can be used when UAT Team has all the instruments and appropriate environment to run UAT.

5.6.2 Hybrid (GSC CP & BTS & GDC TTDC QA Team)

• QA Team and/or BTS may provide tools, configuration, or data and assist the business during the execution.

• UAT Team may consist of members from, GSC CP, BTS and QA Team.

• QA Team does not execute the test cases. Therefore, the GSC CP team can have partially dependent test execution, yet time will be saved.

This approach can be used when the business team partially has data or instruments to perform UAT but, at some points, needs assistance. This approach is best especially when the product has a wide scope.

5.6.3 QA Team only

• QA Team executes UAT on behalf of the business team and presents results.

• UAT Team consists of the requestor and QA Team.

• This is approach is recommended for only trivial projects with minimum effect on the overall business flow.

• This approach can be used when the business team does not have sufficient instruments to run tests; thus, it will be executed by the QA Team manually. For example, checking API responses via Insomnia/Postman.

6 UAT Processes

UAT activities are divided into the following processes:

1. Acceptance criteria definition

2. UAT approach decision and UAT team formation

3. UAT test plan creation

4. UAT preparations

5. UAT execution

6. UAT closure

6.1 Acceptance criteria definition

The requestor’s inclusion is required for the creation of acceptance criteria. Acceptance Criteria is a list of the key outcomes that the Requestor expects to observe following the delivery of the product.

Due to high risks, Requestor and Assignment member should carefully investigate business rules that need to be satisfied, and conditions should be listed for further activity based on a brief bulleted list.

Considering the project’s scope and business rules, this document is mandatory and can be assumed as the most crucial piece of the project’s health.

If the product is large in scope, more than one Acceptance Criteria must be written to cover all aspects of the product.

Properties of Acceptance Criteria:

1. Should be specific and clear

2. Should be testable

3. Should have the clear result: fail or pass

4. Should represent the requirements found in documentation

Examples of Acceptance Criteria:

Acceptance criteria may be provided either as a verification list or in a Given/When/Then format (details may be found in any Agile info sources).

6.2 UAT approach decision and UAT team formation

UAT approach must be decided upon by all teams involved. The representatives of GSC CP, BTS and QA team get together to decide which approach(GCP CP only, Hybrid, QA Team only) is best to take. This phase is important due to approach will change how the UAT testing will be handled as well as the duration.

Following the decision of the approach that will be taken, dedicated UAT testers should be assigned to a UAT team which will carry out the testing phase. By this way responsibilities of each team and individual are clear which in turn will speed up the UAT testing. Depending on the approach taken UAT team can consist of members from GSC CP, BTS and QA team.

6.3 UAT test plan

The UAT test plan is a mandatory and essential document prepared during the project’s or change’s early planning stage. Content below should be created and shared in the document.

UAT Test Plan should be analysed and approved by the Assignment member before implementation. After the approval, the ITSP CHG should also contain this document for future reference.

UAT test plan should include the following items:

1. Reference ITSP CHG

2. UAT Scope

3. UAT Description

4. Features to be tested

5. Features not to be tested

6. Pre-Conditions

7. Acceptance Criteria

8. Test Cases

9. Point of Contact

6.4 UAT preparations

Before UAT Test executions can proceed, the points below should be checked:

• Pre-conditions are mentioned in the UAT plan.

• The environment meets business criteria and is accessible.

• Test data is available for UAT.

• UAT testers are available as scheduled.

• UAT user accounts are created, permissions are given, and accessible.

6.5 UAT environment configurations

By default, QA Team will be creating the test suite in Azure DevOps for UAT test cases to be stored and executed.

• All UAT testers are provided with Basic Licenses in Azure DevOps.

• All UAT testers can access and knows how to execute test cases in Azure DevOps.

• All UAT testers have necessary tools installed and ready to use.

6.6 UAT execution

During the test execution, the points mentioned below should be considered:

• UAT Test cases and Tests Steps are followed thoroughly.

• Defects found are listed and followed up by Requestor and whoever found the defect (a dedicated person can be assigned to follow up on the Defects depending on the scope of the project).

• After a fix is deployed for a defect, a re-test is performed by UAT Team member who initially performed the test.

• During execution of a test case, person executing the test should put as much evidence as possible to allow traceability.

• Test results are stored and saved as proof. Ideally in Azure DevOps.

6.7 UAT closure

After Test Execution is completed, UAT Test Report is provided by the requestor.

6.8 ITSP process flow

The first row indicates the phase in ITSP when UAT-related actions should be done. The second row explains how the actions will be triggered for the Requestor side.

6.9 ARCI matrix

Abbreviation	Definition
A	Accountable: Approves the activity or recommendations from a person or team.
R	Responsible: Responsible for doing the work associated with an activity, either by completing personally or through sole accountability for a team’s output.
C	Consulted: Reviews the output of an activity and provides input but has no approval authority. Provides support to activity and may be consulted by the team during the course of the activity.
I	Informed: Is informed about activities to aid in planning own work.

Activity	Execution approach	Requestor (GSC CP/End user)	Assignment member (BTS)	QA Team (GDC TTDC)
Requirements and Acceptance criteria are documented and signed-off		A/R	R	C
UAT scenarios description		A/R	R	C
Choosing UAT execution approach and forming of the UAT Team		A/R	C	C
Test cases creation	GSC CP only	A/R	C	I
	hybrid	A/R	R	R
	QA Team only	A	R	R
UAT execution	GSC CP only	A/R	C	I
	hybrid	A/R	R	R
	QA Team only	A	R	R
Test report preparation	GSC CP only	A/R	C	I
	hybrid	A/R	R	R
	QA Team only	A	R	R
UAT approval		A/R	I	I
Go decision		A/R	R	I

7 Standard Owner

The owners of the standard are Olga Ovchinnikova and Berhan Cem Ozelbicer.

8 Document control

8.1 Contact person

Questions and feedback regarding this standard should be submitted to Berhan Cem Ozelbicer and Olga Ovchinnikova.

8.2 Document review

The document will be reviewed in case new KPI metrics will be added or deleted on the global level.

8.3 Revision History

Version	Effective date	Purpose of change	Author
9	09-Oct-2023	Revision of the document	Atakan Izdas
8	12-Dec-2022	Review	Olga Ovchinnikova
7	28-Octo-2022	First Version of the Document Published	Berhan Cem Ozelbicer
6	25-Octo-2022	Review	Olga Ovchinnikova
5	23-Octo-2022	Updated Document	Berhan Cem Ozelbicer
4	09-Octo-2022	Third Draft Creation	Berhan Cem Ozelbicer
3	24-Jun-2022	Review	Olga Ovchinnikova
2	15-June-2022	Second version of the document	Berhan Cem Ozelbicer
1	03-March-2022	First version of the document	Berhan Cem Ozelbicer

9 References

References will be added here when necessary.

ANY QUESTIONS?

ASK TEAM