3. 1. INTRODUCTION
Quantification of the test results is required to support “Go”, “No Go” decisions and to quantify one need
to measure. These measurements or metrics will then be used for judgment the quality of product and
diagnosis of problem areas. No wonder defect metrics are the integral part of the testing services.
Defect Analysis is using defects as data for continuous quality improvement of IT applications. An
approach based on already available information is in fact valid to kick start an improvement program!
Defect Analysis and Statistical Trends is a quality model devised by QAT for defect management and
measurement. This technique allows realistic defect categorization, defect analysis, and trend reporting of
applications covered under scope of IT.
DAST deals with defect specific information and answers questions like “What is the number of the
defects?”, “How critical are they for me to roll out?” etc. Irrespective of the applications and domains,
DAST lets you correlate them with each other to form reasonable metrics. DAST reports can provide
feedback mechanism for defect prevention in later iterations/ releases, leading to improve the quality and
productivity.
2 DAST
4. 2. CONCEPT OF DAST
Concept of DAST
QAT does not concentrate on the number of defects in the application instead we recommend in
assessing the risks associated with the release applying DAST & EAST techniques.
DAST emphasizes focus on the under mentioned vital components in of Defect Management (ref. picture
above) –
Defect Reporting
Defect Resolution
DAST
3 DAST
5. 3. APPLYING DAST
DAST emphasizes focus on the vital components in an enterprise context (ref. picture above).
3.1. DEFECT REPORTING
In considering quality, two primary factors are relevant, the application itself (prior release/ version) and
its new features. Any non-conformance of deliverables to specifications, any missing functionality,
usability constraints, mismatches/ disconnects with upstream and downstream processes or applications
are reported as defects. QAT uses a customized open source defect tracking tool, Mantis.
Primary goal of this thread is to guide in detection, analysis and classification of defects. To gain a deeper
understanding of the product quality, it is essential to examine DAST reports from previous releases. Refer
to Section# 7.2 Activity: Defect Detection in Quality Assessment Handbook for more information on
detection.
4 DAST
6. 3.2. DEFECT RESOLUTION
Identify the enterprise context to which the build is released. Figure out inbound and outbound
application interfaces, data flow between databases, marts, warehouses and reports, interfacing with
internal and third party tools, to study the impact of the defect. Finalize on root cause and resolve.
Update Mantis with resolution and closure of defects.
5 DAST
7. 3.3. DAST
DAST produces reports generated out of DDM – Defect Data Mart developed and maintained by QAT
(refer to picture below for DDM logical architecture).
Logical Diagram – Defect Data Mart
6 DAST
8. DDM supports the Section# 7 Thread: Defect Management of Quality Assessment Handbook in terms of
metrics and reporting. Defect metrics generated out of DDM are periodically circulated to project teams,
which are referred to study the trends. Based on the defect trends, necessary process and product
improvement initiatives are triggered and tracked until closure by the respective teams.
7 DAST
