Document name: Document Owner:

ESSP Test Strategy Delivery Excellence Group

DMS section: Information Technology Recipients: Confidentiality level:

EDR: 1-C-IS-OTH-011248501 Eurofins Internal
Type of Document: Field of Application: Business Code:
IT Process Information Systems Group I.T.

Title: ESSP Test Strategy

Summary: Test Strategy

Table of Contents

1. Introduction........................................................................................................................................1
2 QA Testing Scope..............................................................................................................................3
3 Roles and Responsibilities.................................................................................................................6
4 Testing Types.....................................................................................................................................6
5 Test Plans..........................................................................................................................................8
6 Communication................................................................................................................................10
7 Technology/Tools.............................................................................................................................11
8 Test Environment.............................................................................................................................11
9 Strategy for Test Automation...........................................................................................................11
10 Strategy for Test Data......................................................................................................................13
11 Defect Management.........................................................................................................................13
12 Supporting Evidences......................................................................................................................14
13 QA Entry and Exit Criteria................................................................................................................15
14 QA Sign-Off Criteria.........................................................................................................................15
15 Prerequisites and Constraints..........................................................................................................16
16 Suspension and Resumption Criteria for Test Execution................................................................16
17 Test Deliverables.............................................................................................................................16
18 Metrics and KPIs..............................................................................................................................17

1.Introduction

1.1 Project Overview

The objective of this project is to manage and store all the data related to different business object of
the Eurofins ex: Eurofins legal Entity, Business Unit etc. It is envisioned to replace the current EGSS
system by providing varied level of features, ESSP will enable Authorized user to directly verify, create,
modify or close the Business object, creation of deviation/approval of SNCA, ARPPVT change
requests, eCDR documents request, E2E flow process.

1.2 Scope of this document

The purpose of this document is to outline test strategy for ESSP program which determines the
project’s approach to testing. The strategy looks at the characteristics and the risks of the system to be
built, the project timeline and budget, and plans the breadth and depth of the testing effort. The Testing
Strategy will influence tasks related to test planning, test types, test script development and test
execution.
.

Last modified on: 04/07/2022 Approved on (if applicable): 30/06/2022 Version: 2.0

Last modified by: H9AR Approved by (if applicable): Page 1 of 18

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx

1.3 Intended Audience

 Program Director
 Development Manager
 Business Analyst (Product Owner)
 Architect
 IT Development Team
 IT QA Testing Team

1.4 Related Documents

Document Description
“Test Management Process” (EDR: Document that describes the Test Management Process, its
4-979-IS-IPR-01151628) activities, roles and responsibilities.
“Defect Management Guideline” Document that helps to identify, track and manage defects
(EDR: 4-979-IS-ITP-01254925) identified out of IT testing activities.

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 2 of 18

2 QA Testing Scope

2.1 Modules and Functions

Below are the applicable test activities for this project,

1. Test Strategy Definition:
The Test Strategy must define a risk-based approach for testing of a specific IT Program/
Project. The Test Strategy is based upon the results of the risk assessments and an
understanding of the specific IT Program/ Project components and IT Program/ Project
complexity.

2. Test Planning and Design:

A document describing the scope of that Release/ Sprint, resources, prerequisites, test
scenarios and/or associated Test Cases. This approach is repeated in every Release/ Sprint.

3. Test case preparation: Test cases are identified based on 1) Boundary value analysis 2)
Positive and negative test steps for each acceptance criteria.

4. Test Environment Preparation:

Each project should define its own environment's needs. The Test Environment should
consider and define the environments required for testing. Such environments should be
ready before any test execution is done. Ideally Test Environments should be ‘clean’ (no
installations of development tools e.g., Visual Studio etc.) and should closely replicate the
final operational environment where possible.

5. Test Execution:
All tests should be executed according to predefined and approved plans and changes to test
cases and scripts must be maintained under version control.

6. Test Reporting:
Test Reports providing the details of the Test Execution & Defects reported, should be
created for every Sprint within the Release.
Test Summary Reports must be produced that summarize activities and findings and state
the conclusions. Approval of the Test Summary Report constitutes the formal release of
entities for subsequent life cycle steps.

In every sprint, IT QA Testing team will create new Test Cases for new user stories implemented. As
user stories would not cover the system flows from an end-to-end perspective, additional exploratory
testing charters will be created to address these scenarios, wherever applicable.

2.2 Instances

The below listed instances are in the scope of QA Testing.

 Using Azure SQL, Mongo for DB instance.

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 3 of 18

2.3 Other Risks and Dependencies

Risks Impact Mitigation

Environmental / Downtime of infrastructure will Azure PaaS is responsible for all the
Hardware availability to impact the timelines of the infrastructure availability.
be 99.99% project.
Resource dependency Project timelines are not met Each member in the QA team should be
because of QA resource well versed with the functionalities and
dependencies. should be able to provide inputs in the
If the user story grooming absence of any of the resources.
session from BA gets delayed in Adequate collaboration between the QA
the sprint, it will have direct team and the project team, involvement
impact on the downstream in peer reviews of test deliverables,
activities from the QA team. sharing of project information across the
team, swapping of features during test
In case Test Case reviews gets
execution cycles to provide the required
delayed, there will be a risk of
exposure about the full implementation
executing Test Cases which are
in the application.
not reviewed in order to meet
the sprint timelines. User story grooming should be planned
well in advance.
The turnaround time for Test Case
reviews, from the BA team should be
short in order to start test execution in
time.
Work spill over If user story deliveries are The user stories to the IT QA Testing
delayed in a given sprint, it is team should be delivered as and when
going to have an impact on they are marked as “Ready for QA” and
meeting testing timelines and should be tested within the sprint.
might spill over to subsequent
sprint.
Changing Frequent changes to the user Requirement changes has to be
requirements stories or changing user stories controlled and changes within the sprint
towards end of the sprint is should be avoided to the extent
going to impact all the possible. In case it is unavoidable a
downstream activities of the IT detailed impact analysis of the change
QA Testing team thus leading to has to be shared so that IT QA Testing
probable schedule slippage. team can only focus on testing the
impacted areas thus reducing the risk of
test coverage.
Stability of builds for In case there are high number Builds must be stable enough for testing
testing of bugs found in the build, a to begin. Hence a basic smoke test
significant bandwidth of the IT should be performed on the build before
QA testing team will go in using the build. Changes in the build
validating and filing of bugs. must be controlled and there must be

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 4 of 18

 Also due to this testing might thorough code reviews followed by unit
happen on multiple builds thus testing conducted by the Development
reducing the quality of testing. team.
Parallel releases to QA In case of allowing the UAT Releases must be planned with enough
& UAT team to start testing in parallel buffer to avoid parallel testing
to Testing team, we can expect happening between QA and UAT
a higher defect leak percentage teams. Builds should be promoted to
from the IT QA Testing team. UAT only after obtaining QA signoffs.
Also, IT QA Testing team should
consciously make an effort to review
UAT Test Cases and test all scenarios
in functional testing in order to avoid
defect leakage.
Test coverage in Cutting down on the time Adequate time has to be planned for
regression testing allocated will directly impact the obtaining proper test coverage during
test coverage and brings down regression cycles.
the quality of testing. In case of fixing defects during the
regression cycle, adequate information
about the impact fix would have caused
has to be provided in the defect for
Testing team to carry out focussed
regression.
Test coverage for end- In sprint cycles, for the Test To mitigate this IT QA Testing team
to-end scenarios Cases IT QA Testing team would be dedicating 2 hours per sprint
would be focussing more on to perform exploratory testing to cover
covering acceptance criteria for the end-to-end scenarios and will have
user stories. As user stories are them executed as required.
more granular in nature and set
of user stories to meet a
requirement are spread across
sprints, Test Cases written
would miss covering scenarios
from end-to-end perspective.
Prioritization of defects If prioritization of defect is Defect triage should happen for the
missed, then it will have impact prioritization of defects. IT QA Testing
the QA test execution and QA team can support the BA in this activity
signoff for any inputs needed on the defect.
Integration testing Integration testing cannot be Perform proper unit testing to minimize
performed to certify if the issues cropping up during system
application works well with the testing.
two systems. There could be
issues arising within the
application between two
business object.
QA capacity issues As this project involves testing Prioritize the scenarios to be covered on
on multiple browsers, there will each of the browsers in scope, make
be significant efforts needed to use of developer tools or plug-ins
provide adequate test coverage. provided in browsers to simulate the
In case there is a shortfall in QA functionality on other browser. If the
capacity providing adequate test situation demands, escalate to the

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 5 of 18

 coverage on all browsers will be Program Director the need to augment
at stake. IT QA Testing team with additional
resources and also take help from the
BA and Development team in case on
boarding of a test resource is going to
be longer.
Availability of There could be data issues Having Production data even on the QA
Production data for getting reported when the environment will try to address this
testing application is getting tested in issue.
UAT or in Prod.

3 Roles and Responsibilities

3.1 Project IT Testing Roles

Role Actor(s) Responsibilities

Manager Brijesh Trivedi Test Strategy preparation, Test Plan review,
implementing types of testing planned, Test
Execution review, Test Report review and approval,
Test Sign-Off
Test Sanjay Jena, SasiKumar Test Plan Creation, Test Case Creation, Test Case
Engineers Velliangiri, Swathi Review, Test Execution, Defect reporting, Creating
Sivasalapathi, Chiranjeevi Test Reports, Support in defect prioritization, ET
charter creation and execution, Mind map creation.
BA Joanna Bernakowska, Test Case Review, Support in Requirements
Lavanya, Jigar Doshi, understanding, Defect Prioritization
Thejaswini Bs, Sanal K

Note: Please refer to the “Test Management Process” (EDR: 4-979-IS-IPR-01151628) for the complete
list of responsibilities of the IT TESTING roles.

4 Testing Types

Development team performs unit testing of the code and also does a quick functional check to validate
if the user story is functioning as expected before releasing the user story for testing to the IT QA
Testing team.

The testing phase for Fetch project will comprise of System Testing.

Based on the project needs, the below types of testing will be performed by IT QA Testing team:

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 6 of 18

4.1 Sanity Testing

IT QA Testing team will execute a set of Test Cases which evaluates the basic flow of the
application. Based on the result from the Sanity Tests, IT QA Testing team will determine whether
the build is stable enough to proceed with Test Execution activity.
The same Sanity Test Suite will be used in all the sprints for a release unless there is a major
change in the basic feature which requires additional Test Cases to be added to the Sanity Test
Suite.
Also, Sanity tests will only be performed on need basis, like if milestone builds are received, or
whenever DB refresh is done, and the team will not perform any other formal testing prior to Sanity
checks.
Sanity Test Cases can be obtained in AZURE DEVOPS by filtering based on the value “Sanity” in
the field “ETF Type”.

4.2 Functional Testing

IT QA Testing team will execute all Functional Test Cases developed to test the user stories
deployed on Test Environment in each functional sprint. In addition, IT QA Testing team will also
execute the ET Charters created to cover the Should and Could scenarios for the user stories.

4.3 Browser Compatibility Testing

Browser Compatibility Testing will be performed on the following browsers in scope. Main intention
of this testing will be to ensure that functionality works as expected and there are no major issues in
rendering the UI. Currently we are executing all our functional test in latest chrome browser only.
 Microsoft Edge (or current versions during subsequent releases of Fetch)
 Google Chrome version 84 (or current versions during subsequent releases of Fetch)
 Mozilla Firefox version 48 (or current versions during subsequent releases of Fetch)

In order to minimize time needed to test on multiple browsers, IT QA Testing team will make use of
the available developer tools and plug-ins to simulate the different browsers through Microsoft Edge
or Chrome.

4.4 Regression Testing

All Test Cases from the previous sprints qualify as regression Test Cases for the current release. In
order to optimize the regression suite for the release the following guidelines can be adopted.
 All must functional Test Cases related to user stories from the current release and those which
are impacted in the current release are going to be planned and executed in the regression
testing phase.
 All the failed Test Cases in the release for which defects are fixed will be re-executed.
 All critical and major defects from the current release are going to be retested in the regression
testing phase.
 All defects fixed in the release are going to be verified.

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 7 of 18

4.5 Exploratory Testing

NA

The types of testing planned for each sprint are defined in the Test Plan document.

4.6 Non-Functional Testing

Performance testing of ESSP application will be planned based on the non-functional

requirements specified. If needed, performance testing group, which is part of automation team,
will support in creating the scripts, run and report the performance numbers. As this group is
external to the team, they need to be kept informed in advance about the support needed for
them to plan well.

4.7 Data Testing

Data Validation Testing: Data in the database will be validated for correctness by using SQL
queries with appropriate table joins. SQL queries are going to be designed based on schema
information available in the functional specifications or design documents and will be included as
part of Test Case design.

4.8 Performance Testing

NA

4.9 Automation Testing

Automation testing will be performed based upon criteria defined in the Section 9

4.10 Application Security Testing

Scenarios will need to be identified for the same for a release

4.11 User Acceptance Testing:

On successful QA signoff for the release, UAT team comprising of Product Owner and Business
users will perform testing on the UAT servers. They will be running their own UAT scenarios to
validate the functionalities implemented in the release. On successful signoff of UAT the build will
be promoted to Production. IT QA Testing team can support UAT team, wherever needed based
on the bandwidth available.

5 Test Plans

The test plan holds the tests conducted for the core functionalities of respective application.

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 8 of 18

5.1 Testing Activities Overview

The Test Plans are updated for every release in Azure DevOps to provide details on the features that
are Tested. The Sprint Plan holds the details of the features that are tested for the particular Sprint &
thus the release.
The testing activities are planned along with the development team during the Sprint ceremonies.
The High-Level Plan details are available in section 5.3.

5.2 Test Plan Strategy

Test Plans are created, and Test Cases are prioritized for a particular release based on below criteria:

5.2.1 For each Sprint

During the Sprint

The Business Analysts explain the PBI to the Testing Team at the beginning of the Sprint.
The QA Resources creates the Test Cases for all Acceptance Criteria of a PBI.
QA team develops automation scripts for all the insprint test cases.
The Business Analysts review the Test Cases created by the QA Resources.
Test engineers coordinates the selection of Regression Test Cases and smoke test cases with the
Development Team (IT Project Manager).
QA resources executes the reviewed Test Cases for previous Sprint PBI’s.
QA resources executes the selected Regression Test Cases.
QA resources reports defects found during Test Execution.

After the Sprint

Spill over defects and PBI’s are tested by QA team.

5.2.2 For each Release Candidate

QA team executes regression automation test cases

5.2.3 For each Release

Before the last Sprint of the Release

The QA team coordinates the selection of the Regression Tests with the Development Team (Product
Owner, Development Manager).

After the last Sprint of the Release

QA resources executes the selected Regression Test Cases.
QA will utilize the automation scripts (wherever applicable) during regression testing

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 9 of 18

5.3 High Level Test Planning

5.3.1 Test pyramid: As per our current test strategy we are following below test pyramid.

Description Testing Types End

Date/Releases
Main Module/Functions Planned for R1 release

System Testing:
 Sanity Testing
 Functional Testing
 Integration Testing
 Regression Testing
 Smoke testing
Main Module/Functions Planned for R2 release

System Testing:
 Sanity Testing
 Functional Testing
 Integration Testing
 Regression Testing
 Smoke Testing

6 Communication

The communications w.r.t. overall program/project such as sprint ceremonies, team meeting, project
status meetings, etc. are defined in the ESSP Program Management Plan. In addition to these the
following table describes the communication carried out by the IT QA Testing team.

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 10 of 18

 Communication Minimum Information Information Process Enabler
Frequency Provider Recipient
Review and On completion of IT QA Testing IT QA Testing Team, Testing Strategy
validation of Test Strategy Team (IT QA Development Team walkthrough session
Testing Strategy phase Manager) and Stakeholders or offline reviews
Review and Each release IT QA Testing IT QA Testing Team, Test Plans
validation of Test Team IT QA Manager, walkthrough session
Plans Project Team or offline reviews
Review and Each release IT QA Testing IT QA Testing Team, Test Plans
validation of Test Team IT QA Manager, walkthrough session
Plans Project Team or offline reviews
Test Cases for Every sprint IT QA Testing BA Test Cases written
review Team for user stories in
the sprint
Testing Status At the end of the IT QA Testing IT QA Testing Team, Test Reports for
sprint & release Team IT QA Manager, sprints and Test
Development Teams Summary report &
& Stakeholders QA Signoff
document at release
level
Defect Triage Daily (Can be BA, IT QA IT QA Testing Team, Based on incoming
Meeting cancelled if no Testing Team SCRUM Masters and defects in the
Agenda) Development release
Manager

7 Technology/Tools

Tool Purpose
Microsoft Team User Stories, Test Case definition, Tasking & Effort Estimation, Defect tracking
Foundation Sprint Link
Server
Microsoft Test Test plan definition, Test execution & results, Defect tracking
Manager Test Plan
DMS Project Plan:

ETF Test Artifacts:

Reporting Tool Living Documentation reporting tool is used for extracting Test Case details with
steps and screenshots
SQL Client SQL Server 2019 Management Studio
Automation Tools Selenium with Specsflow

8 Test Environment

Refer to section 2.2

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 11 of 18

Please find below the link for the documentation related to test environment verification checklist.

Link: Test Environment Preparation Checklist.xlsx

Test Environment Verification Checklist.xlsx

9 Strategy for Test Automation

Sanity, Functional and regression test cases are automated. The tool used for generating the
automation scripts is selenium. GIT repo is used integrating the automation script in version control
system

9.1 Automation Activity Scope

For Release – 1 Automation for this project is not must for release 1 as development timeframe is short.
For Release – 2 Manual IT QA Testing team (Trained engineers in automation) will develop automation
scripts mainly focusing on the Regression suite and services.

9.1.1 Functional Automation

Sanity, Regression will be considered for automation.

9.1.1.1 Selection of Test cases for Functional Automation

Sanity test cases followed by web service and regression test cases will be considered for
automation with the below priority
1. Sanity test cases
2. Regression test cases

9.1.1.2 Life cycle of an automated test case

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 12 of 18

9.1.1.3 Selection of Test cases for Functional Automation

Only Functionally Validated Test Cases (Functional Validation helps to establish that the software
does what it was originally meant to do), and any above status, can be executed as part of a Test
Cycle/Test Run. Sanity, functional, regression test cases are automated.
Test cases which are automated are update with the automation status as “Automated”, test cases
which cannot be automated (data base test cases) are update with “Cannot be automated” status
ex: Database related PBIs, email verification PBIs, attachment verification on UI.

9.1.2 Service Automation

9.1.2.1 Internal Service Automation

Integration test cases are written by developer.

9.1.2.2 Public Service Automation

NA

9.1.3 Performance Automation

NA

9.1.4 Automation Report

In sprint test cases automation execution and Regression/Smoke test cases automation execution
reports (Specflow+LivingDoc) are generated and shared with all the stakeholders where they can filter
and see either for particular test cases I.e., Regression/Smoke or all the test cases execution report in
one report.
Automation report

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 13 of 18

9.2 Development and Deployment of Automation Scripts

Test cases should adhere to test cases writing guidelines, automated test cases shall not be
modified again. Automation scripts are developed using selenium and are integrated with GIT
repository. The check in triggers the CI / CD Pipeline.

9.3 Communication & Reporting

Automation script execution are demoed to BA / PM at the end of each sprint.

10 Strategy for Test Data

Test data creation are performed by Importing data from excel (automation). Sql scripts are used
for generating test data for manual testing.

11 Defect Management

11.1 Defect Reporting and Tracking

 AZURE DEVOPS will be used for defect reporting and tracking in this project.
 The defect severity and priority (default value) will be assigned initially by the reporter of the
defect. BA’s have to review and reassign the severity and priority based on the business impact
during defect triage. BA’s will also have to change the status to APPROVED if the defect has to
be taken up for fixing in the sprint.
 On accepting the APPROVED defect for fixing, the developer will change the defect status in
AZURE DEVOPS to COMMITTED. After fixing the defect and merging it, AZURE DEVOPS
status will be changed to READY FOR QA.
 IT QA Testing team re-tests the defects which are in READY FOR QA status in AZURE
DEVOPS and updates the defect status accordingly (either to DONE or COMMITTED).

11.2 Defect Retesting

 Once the defect is fixed and the status is” Ready for QA” in AZURE DEVOPS, the defect will be
taken up for retesting on the next build, or on the same build, based on the build deployment
frequency and urgency of verification of the defect.
 The failed Test Cases shall be retested if the defect is fixed in the same release.
 If the resolved defect is working as expected, then the defect status will be changed to DONE in
AZURE DEVOPS. If not, the defect will be reopened (AZURE DEVOPS status – COMMITED).
 As there are going to be defects raised by the non testing members in the team (BAs, Dev, UAT
team, Production), in case those defects aren’t closed by the submitter, the following process
shall be followed to keep track of all fixed defects in the release.
o IT QA Testing team will verify such functional defects not raised by them and will provide
screenshots for having verified them based on the clarity of steps provided in the defect.
In case steps are not clear IT QA Testing team will mark the defect as “Removed” and
term it as “Not a Defect”. Hence it becomes very important for the BA to triage defects

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 14 of 18

 properly before accepting it for fixing and to look out for having all possible information to
reproduce the defect.
o All technical defects like, code review issues, unit testing issues, etc. raised by the
development team have to be closed by the submitter of the defect and will not be
verified by the IT QA Testing team. But even these defects will be part of meeting the
signoff criteria and hence taking these defects to closure becomes very important.

11.3 Defect Severities, Priorities, Defect Types and Defect Statuses

Tags are used to specify the priority of the defects. Please find them below:

0: Product requires successful resolution of the work item before it ships and
addressed soon.
1: Product requires successful resolution of the work item before it ships but
does not need to be addressed immediately.
2: Resolution of the work item is optional based on resources, time, and risk.

Severity:

1 – Critical: Must fix. A defect that causes termination of one or more system components or the
complete system or causes extensive data corruption. And, there are no acceptable alternative
methods to achieve required results.

2 – High: Consider fix. A defect that causes termination of one or more system components or the
complete system or causes extensive data corruption. However, an acceptable alternative method
exists to achieve required results.

3 – Medium: (Default) A defect that causes the system to produce incorrect, incomplete, or inconsistent
results.

4 – Low: A minor or cosmetic defect that has acceptable workarounds to achieve required results.

12 Supporting Evidence

 Steps to reproduce a defect will be provided to the BA’s/Developers in AZURE DEVOPS with
necessary screenshots or documents.
 Test report at end of each Sprint. Test report - Test Plans (azure.com)
 Test summary reports at the end of each Release. Test Summary Progress report - Test Plans
(azure.com)
 QA Sign-off report at the end of each Release. - to be decided by Team

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 15 of 18

13 QA Entry and Exit Criteria

13.1 Entry Criteria

Criteria Owner
Detailed requirements are provided to the IT QA Testing team and Business Analyst
based on these specifications Test Case development starts in
parallel to coding
For major functionality changes, a walkthrough/overview of the Business Analyst
new functionality must be given to the IT QA Testing team
Code review and unit testing completed Development Team
Test Environment setup and Smoke test runs must be completed Deployment Team
successfully
Readiness of Test Plan for the Release and Test Cases for a IT QA Testing Team
Sprint
The package delivered for testing at planned duration must pass IT QA Testing Team
the minimal Sanity Testing

13.2 Exit Criteria

Criteria Owner
All test suites identified for each of the testing cycles are executed IT QA Testing Team
All system and requirement discrepancies are resolved or IT QA Testing Team & BA,
documented and moved to a future release Dev Teams
All the user stories have status as “DONE” in AZURE DEVOPS, IT QA Testing Team, BA, Dev
except for the ones deferred to future release/sprint by the Teams
stakeholders
All defects have status as “Done” in AZURE DEVOPS, except for IT QA Testing Team, BA, Dev
the ones deferred to a future release by the stakeholders Teams
The Test Report and Test Summary Reports have been created IT QA Testing Team & IT QA
and reviewed Manager

14 QA Sign-Off Criteria

Fetch release will be considered as having successfully passed the testing phase if at the end of the
testing sprint, all the below criteria have been met.

Quality Criteria For milestone releases to UAT

% of Test Cases executed >=95%

% of Failed Test Cases <=10%

% of Priority = Must Test Cases that have >=90%
succeeded
Number of Blockers/Critical severity defects open 0
in the release

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 16 of 18

 Number of High severity defects open in the <=5
release
Number of Medium severity defects open in the <=10
release
Number of defects (raised in the release) without 0
target version set (all categories of defects)

Note: All defects prioritized for addressing in subsequent releases should have proper target versions or
iteration paths set in AZURE DEVOPS. Also on meeting the above QA signoff criteria, the defects
which are open in the release at the time of QA signoff should be triaged and moved to subsequent
releases or to the backlog, unless there is a genuine need to have it fixed in the same release.
If the above criteria are not met, then the IT QA Testing team should raise the risks or issues during the
Scrum Ceremonies.

15 Prerequisites and Constraints

NA

16 Suspension and Resumption Criteria for Test Execution

16.1 Suspension Criteria

A Test Run within this Sprint/Release will be suspended if any of the following occur:

 If Sanity Testing fails.

 The build/package is deemed too unstable for testing by IT QA Resources.
 For release candidates only, if the number of defects found or the failed test cases exceed the
quality criteria agreed in the IT Project test strategy.

16.2 Resumption Criteria

Testing will be resumed if the issue that caused testing to be suspended is resolved. If a new
build/package is provided, a new Test Run is started.

Smoke / sanity testing is passed.

17 Test Deliverables

Deliverables When
Test Strategy Beginning of the project and revisited and updated
as and when needed
Test Environment Validated when Test Strategy is prepared and
updated as and when there are any environment
related changes
Test Plan For each process at the beginning of every sprint,
the test plans are updated in Azure Devops link
Test Cases For the user stories planned in a sprint
Test Report End of each Sprint
Test Summary Report During QA signoff (Maintained in Azure DevOps

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 17 of 18

 link)
Test Report (Hard copy extracted from tool) During QA signoff, based on the need

18 Metrics and KPIs

NA

Revision History
Date Version Description Author / Review
Created initial version Mohanraj Kannabiran /
7th Sept 2022 DRAFT
Trivedi Brijesh
17th Sept 2022 1.0 Reviewed and Approved Trivedi Brijesh
rd
03 Aug 2023 1.1 Reviewed QQF5 / Q3AX

File name: https://int.dms.eurofins.local/is/itqms/ITQMS/Test Strategy Template.docx Page 18 of 18