The term is self explanatory, defect logging/tracking of software testing is intended to check bugs/defects in a software application. How do we exactly perform defect logging? What strategies one must adopt in the process of application testing?
Based on empirical facts, it is a known phenomena that a software application is bound to have some defect within itself. No matter how extensive testing has been performed on an application, a bug hides itself mysteriously in the software application. Therefore, one must take measures to devise an effective plan so as to analyse the areas that may produce some form of defect.
Few guidelines that govern the process of an efficient defect tracking procedure are as follows :
Information Capture -This is to determine the minimum amount of information required to begin with. To detect a bug one should be aware of descriptions, products, and screen shots.
Reproduction - It is a little difficult and time consuming task to reproduce a defect. Often it becomes necessary to reproduce some previous bugs to analyse the pattern of defect occurrence.
Prioritize and Schedule -Once a defect is detected, according to its severity and degree of risk involved, it is prioritized and scheduled to be fixed.
Communication -Frequent communication must exist for effective and constructive effort. Details regarding who is responsible for creating and who is responsible for fixing the bug, must be identified.
Environment -To identify the possibility of defect occurrence, the testers must wisely try hardware and software combinations intended for that product to ensure effective bug analysis.
Apart from the guidelines which lay the foundation for an effective defect tracking system, there are few practices that must be followed in order to avoid any further complications.
Best Practices :
It is recommended to follow a unified approach. By that we mean, developers and testers must collaboratively work towards defect tracking mechanism, so that no ambiguity in the process occurs. All those who are using the same defect tracking tool within the organisation with an aim to track defect, must give their feedback on the same.
Users of the defect tracking tool must be at ease with the system. That is, a system must be easy to understand and implement without much complications in the features.
A defect should be clearly defined, that is , the defects logged are easily comprehensible. A defect report should therefore contain the following fields - title, summary, system configuration, steps to reproduce the defect , expected results, and also brief notes having content about essentials.
Avoid defect duplication as much as possible. To reduce the chances of defect duplication, users should query the database before submitting the defect. This shall ensure whether the defect already exists in the database or not. Merging of various defects helps us analyse which defects occur the most so that we can prioritize further issues and requirements.
Match the team's workflow. When a defect is reported, it is verified whether the defect is actually a defect. Allocate resources for fixing the defects, time required by the development and QA teams, cost to be incurred in the process. Finally release the fixed defect. Tracking all these activities are important in effectively meeting defect management.
Integrate with change management. There is a feature in defect tracking tool that lets us integrate tasks at the developer's end with those that are being done on the defect tracking side. Linking of changes in code to defects will provide a better description of the change, provide new approach to release management, simplify QA tasks, provide better accountability, and therefore provide better overall project management.
It is of course the most important factor to involve customers or end users in beta testing of a software . This enhances the chances of defect correction and allows QA team to see defect aspects in a broader spectrum.
Defect Tracking Parameters :
Defect Id - Lists each defect uniquely
Priority - Assigning priority to a defect on the basis of the degree of risk involved
Severity - Determines to what extent the defect can affect the system
Created By - The name of the person who has detected the defect
Created Date - The date on which the defect was captured
Assigned to - The person to whom the defect is reported for resolving it
Resolved Date - The date on which the defect is resolved
Resolved By - The team/person who resolved the defect
Status - Defect fixed or postponed (based on the severity of the defect)
Conclusion :
Defect logging/tracking is basically a continuous activity throughout the life cycle of a software product. Testers and developers consistently look out for defects in the application may be collecting facts from the users, or with the help of defect tracking tools.
.png)
.png)
.png)
.png)
