SOFTWARE QUALITY ASSURANCE

Course Outline

Course Contents
Lecture1 Introduction to SQA and Testing
Lecture 2 Role of SQA in SDLC
Lecture 3 Software Quality Management
Lecture 4 Quality Control Tools
Lecture 5 Software Process Improvement Model
Lecture 6 Configuration and Change Management
Lecture 7 Software Testing - I
Lecture 8 Software Testing - II
Lecture 9 Software Testing Life Cycle
Lecture10 Defect and its Life Cycle
Course Outline (Cont….)

Course Contents
Lecture 11 Quality Data Tracking
Lecture 12 Cost of Quality
Lecture 13 Software Quality Metrics
Lecture 14 SQA in Agile Development
Lecture 15 Introduction of Testing Tool (Guest Lecture)
Lecture 16 Course Recap
 LECTURE # 10

DEFECT LIFE CYCLE

Today’s Plan
 Introduction to Defect Life Cycle
 Defect Stages
 Guidelines on deciding the Severity of Defect
 Guidelines on writing Defect Description
Defect

In simple words, a
defect is an error in
coding or logic that
causes a program to
malfunction or to
produce incorrect or
unexpected results.
Introduction to Defect Life Cycle

 In software development process, the

bug has a life cycle. The bug should go
through the life cycle to be closed.
 A specific life cycle ensures that the

process is standardized.
 The bug attains different states in its life
cycle.
Defect Life Cycle

NEW

OPEN
REJECTED

ASSIGN

DEFERRED
REOPENED TEST

VERIFIED

CLOSED
Defect Stages

 New: When the bug is posted for the

first time, its state will be “NEW”. This
means that the bug is not yet approved.

 Open: After a tester has posted a bug,

the lead of the tester approves that the
bug is genuine and he changes the state
as “OPEN”.
Defect Stages
 Assign: Once the lead changes the state as
“OPEN”, he assigns the bug to corresponding
developer or developer team. The state of the
bug now is changed to “ASSIGN”.
 Test: Once the developer fixes the bug, he/she
has to assign the bug to the testing team for next
round of testing. Before he releases the software
with bug fixed, he changes the state of bug to
“TEST”. It specifies that the bug has been fixed
and is released to testing team.
Defect Stages (Cont..)

 Deferred: The bug, changed to deferred

state means the bug is expected to be
fixed in next releases. The reasons for
changing the bug to this state have
many factors. Some of them are priority
of the bug may be low, lack of time for
the release or the bug may not have
major effect on the software.
Defect Stages (Cont..)

 Rejected: If the developer feels that the

bug is not genuine, he rejects the bug.
Then the state of the bug is changed to
“REJECTED”.
 Duplicate: If the bug is repeated twice

or the two bugs mention the same

concept of the bug, then one bug status
is changed to “DUPLICATE”.
Defect Stages (Cont..)

 Verified: Once the bug is fixed and the

status is changed to “TEST”, the tester
tests the bug. If the bug is not present in
the software, he approves that the bug
is fixed and changes the status to
“VERIFIED”.
Defect Stages (Cont..)

 Reopened: If the bug still exists even after

the bug is fixed by the developer, the tester
changes the status to “REOPENED”. The bug
traverses the life cycle once again.
 Closed: Once the bug is fixed, it is tested by
the tester. If the tester feels that the bug no
longer exists in the software, he changes the
status of the bug to “CLOSED”. This state
means that the bug is fixed, tested and
approved.
Deciding the Severity of Defect - Guidelines

 Indicate the impact each defect has on

testing efforts or users and
administrators of the application under
test. This information is used by
developers and management as the
basis for assigning priority of work on
defects.
Deciding the Severity of Defect – Guidelines
(Cont..)

 A sample guideline for assignment of

priority levels during the product test
phase includes:
Critical
High
Average
Low
Deciding the Severity of Defect – Guidelines
(Cont..)

 Critical / Show Stopper — An item that

prevents further testing of the product or
function under test can be classified as Critical
Bug. No workaround is possible for such bugs.
Examples of this include a missing menu option
or security permission required to access a
function under test.
Deciding the Severity of Defect – Guidelines
(Cont..)

 Major / High — A defect that does not

function as expected/designed or cause
other functionality to fail to meet
requirements can be classified as Major
Bug. The workaround can be provided
for such bugs. Examples of this include
inaccurate calculations; the wrong field
being updated, etc.
Deciding the Severity of Defect – Guidelines
(Cont..)

 Average / Medium — The defects which do

not conform to standards and conventions can
be classified as Medium Bugs. Easy
workarounds exists to achieve functionality
objectives. Examples include matching visual
and text links which lead to different end
points.
 Minor / Low — Cosmetic defects which does
not affect the functionality of the system can
be classified as Minor Bugs.
Guidelines on writing Defect Description

 Be specific. State the expected behavior which did not

occur - such as after pop-up did not appear and the
behavior which occurred instead.
 Use present tense.
 Don’t use unnecessary words.
 Don’t add exclamation points! End sentences with a
period.
 DON’T USE ALL CAPS. Format words in upper and lower
case (mixed case).
 Mention steps to reproduce the bug compulsorily.
Defect Report Sample
Class ahead

Special topics in Software Testing