Skip to main content

QA Vision

Version: 1, effective date: 03-Mar-2022

Olga Ovchinnikova


Contents

1 Standard Description

This document aims to describe the UAT processes that will be embraced by T&T quality assurance standards and followed up in future projects.

2 Document Objectives and Benefits

2.1 Objectives

The objective of the document is to provide a vision about T&T QA and strategy to reach this vision, QA processes initiation, execution, and closure.

2.2 Benefits

(tbd)

3 Definitions

Abbreviation / TermExplanation
SDLCSofware Development Life Cycle
UATUser Acceptance Testing
QAQuality Assurance
CHGChange Request
FRSFunctional Requirement Specification

4 ROLES & RESPONSIBILITIES

Define the roles and responsibilities for activities related to defining, implementing and controlling the standard defined in the document

#Activity<OU 1><OU 2>
1A / R / C / IA / R / C / IA / R / C / I

5 Introduction

The objective of quality assurance for T&T is to make sure that the business objectives are achieved through using the best practices and providing the best collaboration between business and technical parties. QA (Quality Assurance) as a multidisciplinary working area aims to create a set of business processes, generating standards that bind all parties from divergent backgrounds mutually accepted and understandable.

Currently, T&T has a way of working process built by experience and hard work of each responsible, requiring attention and a non-standardized approach of some key principles. Therefore, sometimes miscommunication happens, or unforeseen delays occur during rollouts.

5.1 Vision

Both processes and software testing activities are to be improved based on best practices accepted by the business world and adapting to current JTI T&T systems, having standards to be followed from the preliminary stages of any software change or demands to deployment in production environments while making sure business requirements are met and excepted with a minimum defect.

QAVisionImage.png

The general vision for software systems testing begins with manual QA to be handled by dedicated QA experts and regression scope for applications and projects to be automated and executed regularly or on-demand. New system tests for projects or new functionality should be written and executed once manually and then automated and moved to regression for future projects testing.

5.2 Strategy

The following goals are set:

  1. To bring a software quality mindset that harnesses the best practices in the IT world, such as using ISTBQ standards (ISTQB - The International Software Testing Qualifications Board® is a community that provides an international standard for software testing certification).

  2. To bring live documentation for every process and project where teams from multidisciplinary backgrounds can communicate and collaborate (such as PROBS-C documentations)

  3. To have version control and collective corporate memory to ensure keeping track of system history and prevent losing knowledge

  4. To bring Automation Testing for all T&T systems to reduce cost and time spent on testing

  5. To reduce defects in a production environment where real-life incidents will be prevented on the earliest step of testing before releasing low-quality code to production

  6. To help the Monitoring team to ensure quality standards are met continuously – provide metrics found during testing to be monitored

Steps to be taken:

To bring a software quality mentality our plan is to provide the T&T test team with the trainings below for 2022 Q1-Q2 is:

  • ISTQB Foundation Level
  • ISTQB Test Automation Engineer

To set a documentation line our plan for 2022 Q2 is:

  • Creation of empty templates ready to use for each testing stage:
    • Test plan document template
    • Acceptance criteria document template
    • UAT template
    • Test report document template
    • Test closure document template
    • Lessons learned document template

To bring test automation our plan for 2022 Q3-Q4 is:

  • Setting Test automation standards that are aligned with both DevOps and Business

  • Setting up the development framework

  • Setting up the automation pipeline

  • Expanding the team with relevant competencies

  • BDD Test case creation for automation

  • Development of regressions and periodical execution

To reduce defects in the production environment:

  • Tracking ticket history and category for each system we are testing in production

  • Add the test cases related to the tickets mentioned and test each for every release in the QA stage

  • Increasing the test coverage and creation of detailed test cases, as much as regression with automation for each systemDeliverables for T&T testing

  • UAT - Test Plan

6 Deliverables for Track and Trace

6.1 General Deliverables

Testing standard which explains the T&T testing process on the highest level and is applicable to all T&T applications and projects.

Automation testing standard explains the high-level description of the automation testing approach in T&T.

Automation testing guideline which contains the explanation of how to run the corresponding process for T&T application/project tests in detail, which software is used.

QA team delivers a service so that the Service catalog is in place which consists of resources, capability, which activities the QA team provides, how often, how much time they take.

Test catalog – contains test scope with time estimation for each test. Based on that test catalog we can give an estimation of full testing for projects.

Test classification - how tests are being classified and created, supporting this classification, fast search of the needed test scope, filtering.

Test plan written based on acceptance criteria, below points should be described and assessed for each project’s test plan:

Reference to FRS and ITSP CHG

Test objectives

Test items

  • Software Version where changes will be included
  • If exists user manual

Potential risks

Features and modules to be tested

Features and modules out of test scope

Test approach

  • Test Strategy

  • Tools to be used

  • Defect management

    • Bug trackers to be used
    • exit criteria for defects
  • Description of special requirements, e.g., access to DB, a new tool to be used, VPN, access rights to external sources, etc.

Test Deliverables

  • Periodic Reports

  • Final Report

  • Defect list

Human resources

Approvals for Signoff

Communication

  • Responsible persons with contacts

  • Language

  • Test reports meetings

Test reports will be generated and shared with relevant stakeholders: periodic ones will be used in scrum and sync meetings, the final test report will be shared with all stakeholders for decision-making.

7 How To Get Started With Track and Trace Testing?

There are 3 types of items that may need testing activities:

  1. Change testing

  2. Defect re-testing

  3. Application deployment testing

Software Testing Life Cycle describes in detail the steps of T&T testing.

Change testing

To start testing execution ITSP CHG Tasks must be created and assigned to the T&T Test team. For Change, testing Project manager involves the Test team on the initiation stage of the project to contribute to functional requirements and start creating test scenarios together with the project management team. Thus, Software Testing Lifecycle starts with Requirement Analysis.

Defect re-testing

For each bugfix created as ITSP PRB / INC, the assignee should create a ticket to the test team if he/she needs to test the fix, provide all the background to the test engineer on the step called Requirement Analysis, and contribute to the test plan scope following the Software Testing Life Cycle.

Application deploy testing

All the deploys should be done in the scope of CHG or PRB / INC in ITSP and the assignee should follow the previously described process and involve the Test team in the Initiation step which is Requirement Analysis to contribute to the release notes preparation and proceed with the corresponding test cases creation.

8 Software Testing Life Cycle

STLC contains the following steps:

  • Requirement Analysis

  • Test Planning

  • Test Case Development

  • Environment Setup

  • Test execution

  • Test Cycle Closure

8.1 Initiation

Entry criteria:

  • Business request (CHG/PRJ in ITSP)

Activities:

  • Business request analysis

  • Describing current challenges

  • Describing the suggested solution

  • Assigning UAT responsible persons

Deliverable:

  • Business acceptance criteria (pre-requisite for UAT)

8.2 Requirement Analysis

Entry criteria:

  • Change request
  • Business acceptance criteria

Activities:

  • PM aligning with the test team on the FRS document

  • QA team contribution to technical solution

  • Agreement on Test Types and strategy with the testing team

  • Defining the Test environment

  • Defining the Test data needed

  • Decision of Test automation usage

  • Reviewing Business acceptance criteria based on FRS

Deliverable:

  • Functional Requirement Specification (FRS) document

  • Technical Specification (TS) document

  • Acceptance criteria

  • Final Business Acceptance criteria

8.3 Test Planning

Entry criteria:

  • FRS

  • TS

  • Business acceptance criteria (pre-requisite for UAT)

  • Automation Feasibility Report (Optional)

  • Acceptance criteria

  • Release notes (Optional, for in-house apps if there’s no TS)

Activities:

  • Defining Objective and scope of tests

  • Defining test strategy

  • Test effort estimation

  • Defining Test environment requirements

  • Determining test schedules

  • Determining test reports

  • Determining the resources and roles

  • Raising any potential risk or unusual points which needs to be emphasized

  • Determining test cases to be automated

  • Agreement on test tools availability before execution if needed

  • Describing UAT test plan, detailed test cases

Deliverable:

  • Test Plan Document

  • Test Effort Estimation

  • Test Schedule

  • UAT test plan

8.4 Test Case Development

Entry criteria:

  • FRS

  • Test Plan

  • Automation List (Optional)

  • If exists bugfix list from the previous cycle

Activities:

  • Test case creation

  • Test automation development (optional)

  • Preparation of test data in a test environment

  • Approval of test cases from management level

Deliverable:

  • Requirements Traceability Matrix (RTM)

  • Test Cases

  • Automated Test Cases

  • Test Data

8.5 Test Execution

Entry criteria:

  • Latest Test Plan
  • Latest Automation Test Plan

Activities:

  • Execution of Manual Test Cases

  • Execution of Automated Test Cases

  • Defect/Bug creation

  • Defect/Bug re-testing

  • Execution of UAT if needed

Deliverable:

  • Test Execution Report
  • Defect Report

8.6 Test Cycle Closure

Entry criteria:

  • Final Test Execution Report

  • Defect Report

  • UAT run confirmation

Activities:

  • Evaluation of test results with management

  • Board meeting with stakeholders

  • Defect evaluation

  • Production Go-live decision

  • Lessons Learned session

  • Final Test Reports sign off

Deliverable:

  • Final Test Reports

Results of tests will be presented in ITSP as a report. Proofs with details will be stored in Azure.

9 Document Control

9.1 Standard Owner

Olga Ovchinnikova

9.2 Contact Person

Questions and feedback regarding this standard should be submitted to the Olga Ovchinnikova

10 Revision History

VersionEffective datePurpose of changeAuthor
103-Mar-2022First Draft CreationOlga Ovchinnikova

11 References

Provide here references to relevant documents

ANY QUESTIONS?

ASK TEAM