Defects are the essential part of the software development process. It is believed by most of the people that if there are no defects during the Software Development, there will be no good quality. It’s like medicine are bitter in taste but cures the disease. Defects are like the medicine to the Software Development. When the defects arises, the Software development team try to fix it and give more immunity to the Software and the Software becomes healthy ultimately.
Writing a defect is not a tough task but it requires some of the nice skills. There are no any hard and fast rule to write a defect. But here I’m going to share some of the techniques of writing the nice Defect:
- Be concise and Specific
Defect should be too much lengthy to read. It should contain the information which describes the issue completely and is diverted to the point. Do not make it like an essay. Defect should describe the summary of the issue rather than the mass of the words and sentences
- Provide the appropriate priority to the defect
Not every defect should be of High Priority. It is the human behavior that we think what we do is always should be given higher priority by others. But from the defect priority prospective, we should as flexible as possible. Give the appropriate priority (Critical, High, Medium, Low) as per the complexity of the issue and time frame of the requirement. Since the developers always start working on the Critical and High priority defect first, testers should give them that level of confidence that the critical and high defects are really the first priority defects.
- Always mention the Actual and Expected facts about the defect
This is one of the important things you can apply while logging a defect. Before submitting the defect please make sure that you have written the Expected fact and actual fact related with the defect.
For example if I’m testing Google Home page and I found that search button is not working. Then what I will be writing is as following
Expected: Google search button displaying the search result after clicking the search button
Actual: Google search button not displaying the search button after clicking the search button
- Attach enough evidences and information in the defect
Even though it is not encouraged to make the defect bulky, we while logging the defects we should make sure that we attach as much evidence as possible. The evidence can be database record copied in a spreadsheet, screen shots, log error and so on. The intention of attaching the evidence is that whoever is working on the defect should not come back to the defect logging person and asking about the defect scenarios.
- Provide all the environment information and other technical information
Sometimes defect in one environment (E.g. Test Environment) might not be a defect in another environment (E.g. DEV Environment). Thus you should enlist all the technical details/scenarios like Environment, Code, release number, sprint number etc so that it will be easy for the developer to work on it.
- Fill all the details while opening the defect
Sometimes in the defect review meeting, people might use some filters to get the list of the defect and they might skip some defects whichever don’t have that filter value populated. Thus it is very important to make sure all of the important columns like Project name, Sprint, Assigned to, Severity, priority and so on
- Read your defect before you click submit button
Sometimes you might have repeated the facts, or missed some important information so it’s better to take a small bit of time and read the defect. It is better to make it good at first rather than coming to it again and making the update.
- Title should speak for the defect
Title of the defect should be the reflective of what really is the defect about. You should make sure that Title gives the first impression about the really issue described in the defect. Most of the time during the defect review meeting of the big project, the DRB (Defect Review Board) team will not have the enough time to go through the description of the defect, thus the title should make clear them about what is the defect really about and it should be self descriptive.
Conclusion:
Thus while writing the defect you should make sure that you don’t create defect within the defect. Defects are not really a problem, rather they are the guidelines for the success of the software development.
