Pages

Men

rh

7/15/2012

Defect Management


Defect – Definition

Error: A human action that produces an incorrect result. “

Fault: A manifestation of an error in software. A fault, if encountered may cause a failure. “

Failure: Deviation of the software from its expected delivery or service. “

A deviation from expectation that is to be tracked and resolved is termed as a defect. An evaluation of defects discovered during testing provides the best indication of software quality. Quality is the indication of how well the system meets the requirements. So in the context defects are identified as any failure to meet the system requirements.

Error:
Is an undesirable deviation from requirements?
Any problem or cause for many problems which stops the system to perform its functionality is referred as Error

Bug:
Any Missing functionality or any action that is performed by the system which is not supposed to be performed is a Bug.
Is an error found BEFORE the application goes into production?

Any of the following may be the reason for birth of Bug
1. Wrong functionality
2. Missing functionality
3. Extra or unwanted functionality

Defect:
A defect is a variance from the desired attribute of a system or application.
Is an error found AFTER the application goes into production?

Defect will be commonly categorized into two types:
1. Defect from product Specification
2. Variance from customer/user expectation. 

Failure:
Any Expected action that is supposed to happen if not can be referred as failure or we can say absence of expected response for any request.

Fault:
This generally referred in hardware terminologies. A Problem, which cause the system not to perform its task or objective.

12.2.Types of Defects

Defects that are detected by the tester are classified into categories by the nature of the defect. The following are the classification
Showstopper: 
A Defect which may be very critical in terms of affecting the schedule, or it may be a show stopper – that is, it stops the user from using the system further

Major:
A Defect where a functionality/data is affected significantly but not cause a showstopping condition or a block in the test process cycles.

Minor:
A Defect which is isolated or does not stop the user from proceeding, but causes inconvenience. Cosmetic Errors would also feature in this category

Defect Reporting
Defects or Bugs when detected in the application by the tester must be duly reported through an
automated tool. Particulars that have to be filled by a tester are
Defect Id: 
Number associated with a particular defect, and henceforth referred by its ID

Date of execution: 
The date on which the test case which resulted in a defect was executed

Defect Category: 
These are explained in the next section, ideally decided by the test leader
Severity: 
As explained, it can be Major, Minor and Show-stopper

Module ID: 
Module in which the defect occurred

Status: 
Raised, Authorized, Deferred, Fixed, Re-raised, And Closed.

Defect description:
Description as to how the defect was found, the exact steps that should be taken to simulate the defect, other notes and attachments if any.

Test Case Reference No: 
The number of the test case and script in combination which resulted in the defect.

Owner: 
The name of the tester who executed the test cases

· Test case description: 
The instructions in the test cases for the step in which the error occurred

Expected Result:
The expected result after the execution of the instructions in the test case descriptions

Attachments: 
The screen shot showing the defect should be captured and attached

Responsibility: Identified team member of the development team for fixing the defect.


Tools Used
Tools that are used to track and report defects are,

ClearQuest (CQ)
It belongs to the Rational Test Suite and it is an effective tool in Defect Management. CQ functions on a native access database and it maintains a common database of defects. With CQ the entire Defect Process can be customized. For e.g., a process can be designed in such a manner that a defect once raised needs to be definitely authorized and then fixed for it to attain the status of retesting. Such a systematic defect flow process can be established and the history  for the same can be maintained. Graphs and reports can be customized and metrics can be derived out of the maintained defect repository.

TestDirector (TD):
TestDirector is an Automated Test Management Tool developed by Mercury Interactive for Test Management to help to organize and manage all phases of the software testing process, including planning, creating tests, executing tests, and tracking defects. TestDirector enables us to manage user access to a project by creating a list of authorized users and assigning each user a password and a user group such that a perfect control can be exercised on the kinds of additions and modifications and user can make to the project. Apart from Manual Test Execution, the WinRunner automated test scripts of the project can also be executed directly from TestDirector. 
TestDirector activates WinRunner, runs the tests, and displays the results. Apart form the above,
it is used for

  • To report defects detected in the software.
  • As a sophisticated system for tracking software defects.
  • To monitor defects closely from initial detection until resolution.
  • To analyze our Testing Process by means of various graphs and reports.

Defect Tracker
Defect Tracker is a tool developed by Maveric Systems Ltd. an Independent Software Testing Company in Chennai for defect management. This tool is used to manage the defect, track the defect and report the defect effectively by the testing team.

Defects Meetings
Meetings are conducted at the end of everyday between the test team and development team to discuss test execution and defects. Here, defect categorizations are done. Before meetings with the development team, test team should have internal discussions with the test lead on the defects reported to the test lead. The process ensures that all defects are accurate and authentic to the best knowledge of the test team.

Defects Publishing
Defects that are authorized are published in a mutually accepted media like Internet or sending the issue by email etc.
Reports that are published are
Daily status report
Summarized defect report for the individual domain / product if any
Final defect reported

Test down Times:
During the execution of the test, schedules prepared earlier may slip based on certain factors. Time lost due to these should be recorded duly by the test team

1) Server problems
  • Test team may come across problems with the server, on which the application is planted.      Possible causes for the problems are
  • Main server on which the application may have problems with number of instances on it slowly down the system
  • Networking to the main server or internal network may get down Software compatibility with application and middleware if any may cause concerns delaying the test start

2) New version of databases or middleware may not be fully compatible with the applications
3) Improper installation of system applications may cause delays
4) Interfaces with applications may not be compatible with the existing hardware setup
5) Problems on Testing side / Development side
6) Delays can also be from the test or development teams likely
7) Data designed may not be sufficient or compatible with the application (missing some parameters of the data)
8) Maintenance of the parameters may not be sufficient for the application to function
9) Version transferred for testing may not be the right one



Defect Life Cycle





























No comments :

Post a Comment