HOME TESTING TELECOMS RESOURCES CLIENTS CONTACT
 
 
Intro Models Documentation Design Scripting Tools Execution Defects Reporting  
 

Raising defects

When running tests there will be a time when an actual result differs from the expected result. When an error is detected during testing first step is to determine if this is a test error. If the test is in error it should be corrected and re-run, if the test is correct and is the system response that is in error there is a system defect. The defect could exist in the applciation software, the environment or the requirement specification.

What to record in a defect

If a defect management tool is being used such as Quality Center, SpiraTest or Bugzilla, there will be a configurable set of attributes that are available to record, an example set could be:

Attribute Description
Defect ID Automatically allocated defect identifier
Status Where the defect lies in the defect lifecyle of the project
Title Defect title, often contains searchable keywords
Description Detailed description of the bug including steps on how to reproduce
Incident date Date on which the defect was raised
Detected by Person that raised the defect
Assigned to Person that is tasked with fixing the defect
Priority Business priority as defined in the Test Strategy
Severity The technical severity as defined in the Test Strategy
Subsystem The component suspected to contain the defect
Test Phase The test phase at which the defect was discovered
Test ID Identity of the test that discovered the defect
Environment Environment on which the defect was observed
Build ID the build level when the defect was detected
Attachments Evidence of the defect such as screenshot or logfile fragment

Defect priority and severity

It is important to differentiate between defect severity and defect priority. These should be clearly defined at the start of the project and included in the Test Strategy.

Defect severity is a measure of the seriousness of a defect from a testing perspective. If the defect only prevents a single test from being completed it may be considered a low severity defect, if however the defect blocks all testing it would be marked as a critical severity defect.

Defect priority is a measure of seriousness from a business perspective. If the defect prevents a major business function from operating it would be classified as a very high priority defect, if the defect had only minor business impact it would be set as low priority.

The following table gives examples of defect severity and priority combinations:

Defect Priority Defect Severity Example Scenario
Low Low Spelling mistake on a rarely generated error page
Low High Unable to set up bulk test accounts although single accounts can be set up manually
High Low The company logo is incorrect on the index page of the website
High High The webserver won't start and a holding page is permanently displayed

Status and the defect lifecycle

One of the attributes recorded in defect management tools is the defect status. This represents the point in the defect lifecycle that the defect is currently at. The defect lifecycle is defined in the Test Plan, configured in the defect managemnt tool and describes the states that the defect can reach and under which conditions the defect can transition from one state to another. The following diagram is an example of a simple defect lifecycle

A diagram of a simple defect flow

Defect state transition diagram


The state transition table would be configured in the defect tool and for this example would be:

Current Status Next Status Reason for Transition
Open Assigned The defect has been raised in an open state and assigned to a developer
Assigned Rejected The developer does not accept the defect and has returned it to the tester
Assigned Fixed The developer has accepted the defect, fixed it and committed the fix to the code repository
Fixed Ready for Retest The system has been rebuilt with the fix included and deployed to the test environment
Rejected Assigned The tester has added further supporting evidence and returned the defect to the developer
Rejected Closed The defect was raised in error
Ready for Retest Closed The defect solution has been tested successfully

To effectively manage defects a suite of test reports should be created and run periodically.

Author:

     
Home      |      Testing      |      Telecoms      |      Resources      |      Clients      |      Contact     |     Care Database
 Copyright © 2016 Chic Computer Consultants. All rights reserved