SOFTWARE TESTING

Testing Life Cycle – Bug Life Cycle

Jagan Mohan Julooru

Differences between QA, QC and Testing

• Quality Assurance: A set of activities designed to ensure that the development

and/or maintenance process is adequate to ensure a system will meet its
objectives.

• Quality Control: A set of activities designed to evaluate a developed work

product.

• Testing: The process of executing a system with the intent of finding defects.
(Note that the "process of executing a system" includes test planning prior to the
execution of the test cases.)

QA activities ensure that the process is defined and appropriate. Methodology and
standards development are examples of QA activities. A QA review would focus on the
process elements of a project - e.g., are requirements being defined at the proper level of
detail.

QC activities focus on finding defects in specific deliverables - e.g., are the defined
requirements the right requirements

Testing is one example of a QC activity, but there are others such as inspections

The difference is that QA is process oriented and QC is product oriented.

Testing therefore is product oriented and thus is in the QC domain. Testing for quality
isn't assuring quality, it's controlling it.
Quality Assurance makes sure you are doing the right things, the right way.
Quality Control makes sure the results of what you've done are what you expected.

Jagan Mohan Julooru

Test Development Life Cycle

Test Specifications

The test case specifications should be developed from the test plan and are the second
phase of the test development life cycle. The test specification should explain "how" to
implement the test cases described in the test plan.

Test Specification Items

Each test specification should contain the following items:

Case No.: The test case number should be a three digit identifer of the following form:
c.s.t, where: c- is the chapter number, s- is the section number, and t- is the test case
number.

Title: is the title of the test.

ProgName: is the program name containing the test.

Author: is the person who wrote the test specification.

Date: is the date of the last revision to the test case.

Jagan Mohan Julooru

Background: (Objectives, Assumptions, References, Success Criteria): Describes in
words how to conduct the test.

Expected Error(s): Describes any errors expected

Reference(s): Lists reference documententation used to design the specification.

Data: (Tx Data, Predicted Rx Data): Describes the data flows between the
Implementation Under Test (IUT) and the test engine.

Script: (Pseudo Code for Coding Tests): Pseudo code (or real code) used to conduct the
test.

Test Results Analysis Report

The Test Results Analysis Report is an analysis of the results of running tests. The results
analysis provide management and the development team with a readout of the product
quality.

The following sections should be included in the results analysis:

• Management Summary
• Test Results Analysis
• Test Logs/Traces
•

Software Quality Concepts

• Quality is conformance to product requirements and should be free.

• Quality is achieved through prevention of defects .
• Quality control is aimed at finding problems as early as possible and fixing them.
• Doing things right the first time is the performance standard which results in zero
defects and saves the expenses of doing things over.

Jagan Mohan Julooru

 • The expense of quality is nonconformance to product requirements
• Quality is what distinguishes a good company from a great one.
• Quality is meeting or exceeding our customer's needs and requirements.
• Software Quality is measureable.
• Quality is continuous improvement.
• The quality of a software product comes from the quality of the process used to
create it.
• Quality is the Entire Company's Business
• Our Quality network testing products help make our customers successful.

Bug Life Cycle

Jagan Mohan Julooru

States of a Bug

UNCONFIRMED
This bug has recently been added to the database. Nobody has validated that this
bug is true. Users who have the "canconfirm" permission set may confirm this
bug, changing its state to NEW. Or, it may be directly resolved and marked
RESOLVED.
NEW
This bug has recently been added to the assignee's list of bugs and must be
processed. Bugs in this state may be accepted, and become ASSIGNED, passed
on to someone else, and remain NEW, or resolved and marked RESOLVED.
ASSIGNED
This bug is not yet resolved, but is assigned to the proper person. From here bugs
can be given to another person and become NEW, or resolved and become
RESOLVED.
REOPENED
This bug was once resolved, but the resolution was deemed incorrect. For
example, a WORKSFORME bug is REOPENED when more information
shows up and the bug is now reproducible. From here bugs are either marked
ASSIGNED or RESOLVED.
RESOLVED
A resolution has been taken, and it is awaiting verification by QA. From here
bugs are either re-opened and become REOPENED, are marked VERIFIED, or
are closed for good and marked CLOSED.
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate
resolution has been taken. Bugs remain in this state until the product they were
reported against actually ships, at which point they become CLOSED.
CLOSED
The bug is considered dead, the resolution is correct. Any zombie bugs who
choose to walk the earth again must do so by becoming REOPENED.

Jagan Mohan Julooru

Resolution of a Bug

FIXED
A fix for this bug is checked into the tree and tested.
INVALID
The problem described is not a bug
WONTFIX
The problem described is a bug which will never be fixed.
LATER
The problem described is a bug which will not be fixed in this version of the
product.
REMIND
The problem described is a bug which will probably not be fixed in this version of
the product, but might still be.
DUPLICATE
The problem is a duplicate of an existing bug. Marking a bug duplicate requires
the bug# of the duplicating bug and will at least put that bug number in the
description field.
WORKSFORME
All attempts at reproducing this bug were futile, reading the code produces no
clues as to why this behavior would occur. If more information appears later,
please re-assign the bug, for now, file it.

Severity levels of a Bug

This field describes the impact of a bug.

Blocker Blocks development and/or testing work

Critical crashes, loss of data, severe memory leak
Major major loss of function
Minor minor loss of function, or other problem where easy workaround is
present

Jagan Mohan Julooru

Trivial cosmetic problem like misspelled words or misaligned text
Enhancement Request for enhancement

Priority levels of a Bug

This field describes the importance and order in which a bug should be fixed. This field is
utilized by the programmers/engineers to prioritized their work to be done. The available
priorities are:

P1 Most important
P2
P3
P4
P5 Least important

Jagan Mohan Julooru