Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 12

QUALITY CONTROL PROCESS

Software Quality Assurance (SQA) Objective

The Quality Process at CEM is undertaken to ensure that the Quality of the
project /product are achieved by applying clearly defined quality assurance
strategies.

This QA process is applicable to all projects / products that are created or


enhanced by the CEM project teams.
PROCESS FLOW

Consultant PM QC DEV DELIVERABLES

PROJECT PLAN TEST PLAN


TEST PLAN

REQUIREMENTS GAP ANALYZED SBP DRAFT SBP ANALYSIS SBP


FRD

CONFIG CONFIG CONFIG


CONFIGURATION
DATA REVIEW RELEASE

APPROVED SBP REVIEW UNIT TEST


FRD CASE

SCENARIO
SCENARIO TEST CASE
CLIENT
REVIEW TEST CASE
SCENARIOS
QUALITY ASSURANCE PROCESS

PM QA DEV DELIVERABLES

ITERATIVE
PROCESS

UNIT TESTED
TEST DEPLOYMENT
EXECUTION

NO YES

RELEASE DEFECT
DOCUMENT REMEDIATION
REPORT

RELEASE
DOCUMENT
Required details to be gathered

Field Name Details Description

Navigation Human resource -> Employee master -> Project Management  -> Project Setup

Description < Guide the purpose of the field >


Help Text Mention the help text to be displayed at the bottom.

Data flow from User entry (or) From Master (or) Through any field selection

UI control type Editable/ Non Editable Textbox  (or) List box  (or) Caption button (or) …
Mandatory  field No / Yes
< Field label > Default value Blank  (or) Specify the default value
Business logic * < mention where the field impacts and what does the field impact >

Mention the conditions that field need to satisfy :


Should list only the values which are <condition>

Validation rules * 
 Soft warning / hard warning “<warning message>” if invalid data is entered.

 Should be enabled / disabled when <condition>.


 Do not allow to edit when <condition>
Test Plan Document
<project name>
< Ver sion >

Prepa red for

CEM Internal Quality Control

Project

Microsoft D ynamics AX 201 2 R3 – < Mo dule >

Prepa red by

< Prep ared b y >

Reviewed by

< Reviewed By >

TEST PLAN

Test plan is delivered by Quality team and approved by Project Manager


before tests are executed.
 Testing strategy
 Entry and Exit criteria
 Test schedules
 Resource allocation

Below mentioned the Test Plan Template

Test Plan
TEST CASE

• Test cases are prepared based on the scenarios / functional documents


provided by the end user.
• Test Cases are created by following CEM standards in defined Test case
Template that summarizes the status of test cases in each independent
modules.

Below mentioned the Test case template

Test Case
Template.xlsx
DEFECT REPORT

Defects are to be classified based on its priorities and severities. The


definitions of P1 to P4 defects are as given below:
Priority Description Action
Client cannot use the fundamental functions of the product Resolve immediately
P1 – Critical rendering it thus unusable. The feature having the problem is
business and time critical.

Important function is not available or produces wrong result. Resolve ASAP.


P2 – Major Critical functions of the product remain intact. The problem is not
stopping critical business operations but is an inconvenience.
Functions of low importance produce wrong results. Resolve when working on
P3 – Minor
the next build.
Function of low importance with no business impact (viz., Resolve before delivery.
P4 – None
Cosmetic changes)
Assessment of Quality failure
KEY AREAS RISK FACTORS SOLUTION
Discrepancy in knowledge over actual functionality of the  Training sessions
PROCESS KNOWLEDGE system.  KT over the process.

There was inadequate time and resources planned for the  Test process schedule has to rely on
full testing of the software. Testing Plan.
INADEQUATE TIME &
RESOURCE  Adequate resource to be placed for
Testing.
The test cases were not thorough in testing certain  Scenarios are to be gathered from
components of the software. This was not evident until after user prior development.
the release of the software with customers on live sites. 
SCENARIO CASES All possible scenario’s has be
analyzed prior testing.

The test resource was not thorough enough in capturing  Test resource has to be trained on
how a user uses the application. Hence the user detects testing strategies.
TESTING PRACTICE bugs that the tester overlooked.

Insufficient system testing is done prior deployment.  Best practice has to be followed and
system test has to be performed and
SYSTEM TESTING confirmed by QC prior deployment.
Quality Check list

Application Quality Assurance checklist is intended to ensure customized


applications adhere to development practices that promote quality
solutions.

Each section of this Checklist template must be completed in full. If any


particular section is not applicable to this project, then can be mentioned
as Not Applicable with a valid reason

No sections are provided optional.

QC checklist
THANK YOU

You might also like