Defect Management

Why is defect management process important in software development teams?

This is a formal way of identifying, fixing and tracking the defects in the system. If defect management process is not followed it will be very hard to know the quality of the system and also will be very difficult to know the status of the defect like how many defects raised, whether any developer working on these defects and also will be difficult to know if anyone re-tested the defect.

What are the fields in a bug report? • Why do defects have priority and severity?

Different field in bug report are Defect ID, Defect Description, Version, Steps to reproduce the defects, Date Raised, Reference (Like requirement doc, design doc or screenshots), Detected by, Status (New, Assigned, Deferred, Fixed, re-test, re-open, close), Fixed By, Date Closed, Severity and Priority.

Severity and Priority helps to understand the criticality of the defect and the impact on the system.

When does a defect gets deferred? • How do you deal with an inconsistent defect?

Defect gets deferred when there are other priority defects to be fixed and also when the impact of the deferred defect on the system is low. There could be also management/customer decision to defer the defect to the next version.

Dealing with Inconsistent defect: Always have detailed steps in your test case, if possible record the flow or take screenshots as for as possible. Do not sit on inconsistent defect, discuss with senior testers and test managers / lead and their experience will help you to deal with these kind of defects.

How do you log a defect? • Can you name a defect that has high priority and low severity?

Defect logging is generally done through a tool like Jira, HP QC, ALM , Microsoft TFS etc.. or if the organization is very small you can use excel spreadsheet as well.

The defect logged should have at least Defect ID, Defect Description, Version, Steps to reproduce the defects, Date Raised, Reference (Like requirement doc, design doc or screenshots), Detected by, Status (New, Assigned, Deferred, Fixed, re-test, re-open, and close), Fixed By, Date Closed, Severity and Priority.

The logo of the company is set wrong can be a good example of High priority and low severity.

When does a defect gets rejected by the developer?

Bug gets rejected due to one or combination of the below reasons

1. Defects not reproducible
2. Requirement not clear (everyone have their own understanding)
3. Duplicate Defect
4. Test Description and test steps are not clear
5. Test data used was not correct
6. Test Environment issue (Hardware, software, wrong version/build  ...etc)
7. Wrong understanding of the requirement by the tester
8. Requirement got changed but not informed to the test team (Communication issue)

 

What is a change request and how does a change request gets handled?

If any changes comes after the requirement is baselined will be called as change request.

Change request will go to the change control board (CCB) which will have the stakeholders from the customer and the software development team. First the change will be discussed on the business impact, time line and changes required to the system. Once the development team does the impact analysis of the change and give their feasibility report, the CCB will approve or reject the defect.

How do you analyze the root cause of a defect? • What is defect triaging?

Either by 5 why technique, Brain storming or using fish bone diagram we can do a root cause analysis of software defects. First step is to categorize the defects and group the similar defects and use pareto analysis and find those 20% defect category causing the 80% of the defects. Use the technique like 5 why, brain storming or fish bone to arrive at the root causes for these 20% of the defects. Have an action item for these defects and do the systemic changes so the defects will not reoccur in the future releases.

Defect Triaging : Defect triaging is a meeting initiated by the test lead and attended by Project managers, developers , testers , BA and product owner. Here each defect will be discussed, and the priority and severity will be set and also the testing team will give their view of any defects blocking their testing process. Even the defects rejected reason will be discussed here. Also the developers will give their timeline in fixing the agreed defects in this meeting. Any defects to be deferred to the next release will also be discussed here.