A mismatch in the developed application and its desired specification or in testing terms the variation in the expected and actual test results is known as Defect. Different organizations have different names to describe this variation, commonly defects are also known as bug, problem, incidents or issues.
An evaluation of defects identified during different testing phases provides the best indication of software quality.
4.1 Classification of Defects
Defect severity or Impact is a benchmark of classifying software defects and it also indicates the degree of negative impact of the defect on the system
The severity of defects can be classified as follows:
·Critical/Urgent: The defect prevents the test team for further processing and testing. The development team as well as the higher management must be informed immediately and corrective measures should be taken.
Consider about the testing on a secure website and when any test user tries to log into the system with proper credential, an http page not found message is displayed. Now this can be considered as a Critical or Urgent defect for the test team
·High : The defect affects major functionality or major data or it affects selected processing to a significant degree. It may cause data loss or could cause a user to make an incorrect decision or entry. Generally the Development team should fix the issue or defect within 0-24 hours.
·Medium : The problem affects selected processing, but has a work around that allows continuous processing and testing. It has an easy work around and development team generally fix the issue within 24-48 hours. Cosmetic problems that hamper usability can be an example of Medium defects
·Low: These kind of defect neither affect functionality nor data. These defects do not impact productivity or efficiency. Spelling mistake within the content of inner page of a web site can be treated as a low category defect.
Defect Priority signifies how important it is to fix this defect. The defect priority is generally assigned by the development team and the values which defect priority takes are:
Now let’s discuss some important scenarios related to severity and priority:
·High Priority & High Severity : This is an error which occurs on the main functionality of the application and the end user is unable to use the system.
·High Priority & Low Severity : This is an error which is very less important from a user perspective but has a high business impact. Spelling mistakes on the home page or on heading of a web application can be considered as an example for this kind of defect.
·High Severity & Low Priority : An error which occurs on the functionality of the application (for which there is no workaround) and will not allow the user to use the system but the functionality is rarely used by the end user can be considered as an example of this kind of defect.
4.2 Defect Life Cycle
Defect Life Cycle is the journey of a defect from its identification to its closure. Now this life cycle varies from organization to organization but the basic life cycle resembles the following :
4.3 Defect Reporting
The key to make a good report is providing the development team as much information as necessary to reproduce the bug. These can be broken into the following:
· Give a brief description of the bug or defect
· List the steps that are needed to reproduce the issue
· Provide all the details on the test data used to get the issue
· Provide all the required screen shots of the defect to the development team
· Provide the opinion from a tester’s perspective
Generally the more information is shared by the test team, the easier it will be for the development team to determine the problem and fix the issue. But a bug report is a case against a product so the report should be concise such that someone who has never seen the system can follow the steps and reproduce the issue.
4.4 Defect Tracking
After a defect has been found it must be reported to the development team so that they can fix the issue. A tester logged a defect and the initial state of a defect is ‘New’. If a business analyst is available within the project, then the tester assigns the defect to him. On absence of a business analyst the project lead or the coordinator reviews the defect. If the defect is valid then it will be assigned to the development team lead and the status will be ‘Assigned’ , otherwise the defect is marked as ‘Rejected’. The BA or lead can marked the defect as ‘Duplicate’ if there was a same bug reported earlier and ‘Deferred’ if this is a future enhancement.
Once the development team has fixed the issue and provides the test team a new build, the defect status is changed to ‘Fixed’ and it will be assigned back to the test lead. The test lead reviews it and assigns the defect back to the tester with the defect status as ‘Ready For Retest’. The tester verifies it once again and if the functionality works as specified the tester marks the defect status as ‘Closed’ and also passes the relevant test case.
On re-testing the defect if the issue still persists then the tester changes the status as ‘Re-Opened’ and assigns the defect back to the lead (the same cycle will be followed)
4.5 Defect Analysis
Analysis of defects found during testing can be used to generate software process improvements in an organization. This defect analysis is using defects as data for continuous quality improvement and generally defect analysis classify defects into categories and tries to find out the root cause to direct process improvement efforts. The defect analysis can be done according to the following:
4.5.1 Defect Pareto Chart
A Pareto chart is a special type of bar chart to show the defect type with the highest frequency of
occurrence of defects. The Pareto chart provides an effective way to graphically show
the significant problems and causes are in a process. A Pareto chart can be used when data is available or can be readily collected from a process
A series of tasks is required to use Pareto chart for a process and the steps are:
- Define the problem clearly
- Collect sufficient data or use historical data if available or retrievable
- Sort the collected data in descending order by occurrence or frequency of cause and characteristics
- Construct bar chart to correspond to sorted data with ‘X’ axis as the Cause/Characteristic of defect and ‘Y’ axis as the Frequency/Number of occurrence of the defect
- From the Pareto chart determine the vital few causes and these defect types should be given higher priority and must be addressed first
4.5.2 Root Cause Analysis
Root Cause Analysis is the method of finding the issue which mainly causes the fault or problem within the designed system or process.
The root cause analysis of the defects not only reduces the defects to improve quality but also lead to implement the corrective measures to ensure that those defects will not be re-produced in future.
One of the tools used to facilitate RCA is a simple graphical technique called Cause-and-Effect diagram/ Fishbone diagram / Ishikawa diagram invented by the late Kaoru Ishikawa, a quality leader from Japan. This technique helps identify the causes of problems related to processes, products and
Services and by better understanding of the work process and by several brainstorming sessions team can reach probable root causes of the problem. Implementing or developing a cause and effect diagram for a process or product requires the following steps:
- Arrange one or many brainstorming sessions within the team to identify a problem (effect) with a list of potential causes
- Construct a basic fish bone diagram with the effect at the right side and the major causes as the big branches to the problem as shown below:
Use the results of brainstorm sessions until lowest level sub cause is identified as shown below
- Once the sub causes are identified the team review, check and verify with the process and the causes which strongly affect are resolved
- This process continues to identify all validated root causes
4.6 Defect Prevention
Defect Prevention is one of the most important activities in any software project and the purpose is to identifying the defects and take corrective measures so that they will not re-occur in future releases. The best approach to defects is to eliminate them altogether from the system but it is actually impossible in real life. So identifying and implementing the best defect prevention plan should be given high priority for a project.
Defect prevention should begin with the identification of the most critical risk associated with the system. Strategies which is commonly termed as ‘Defect Prevention Plan’ ( DP Plan) is established to prevent defects. A DP coordinator is generally assigned in project to provide the plan to the stake holders.