Each defect logged by a tester will contribute to improving the software’s stability, but there are several factors to consider when reporting a defect.
Raising defects with only the intention of increasing the number of those found may be an objective of the test team, but that’s not usually very helpful to the overall development. When reporting defects, the focus must be on raising valid and acceptable defects.
Quick tips to consider when reporting a defect
The way that defects are reported can vary according to the type of tool used. Some demand several inputs to be provided and others may be configured to report only selected details. Whether the method used for defect reporting involves tools or manually using a spreadsheet, there are a few key points we must always remember to include when reporting a defect.
Adequate Defect Details
Every defect logged must have a sufficient description that can be clearly understood by the developers so they can understand and be able to recreate the bug. Provide steps so they can reproduce the exact path in which the issue occurred. Many a time, the defect is not generic and may only happen in specific scenarios. Therefore, it’s essential to make clear the steps taken by the tester when they discovered the bug. If a tool is used to log defects, the defect IDs will be auto-generated so nothing further needs to be done.
Let’s consider a case when defects for retesting are assigned to someone other than the reporter. If the defect to be retested does not have the problem and steps clearly stated, the re-tester is likely to spend a lot of time getting to understand the issue, or might even mark it as closed because they haven’t been able to validate it correctly. To avoid a back-and-forth among the team to understand the exact problem, and so the defects can be fixed completely and retested well, providing adequate details while creating a defect is essential. Attaching screenshots and videos to better illustrate the situation can also help to enable quicker fixes.
Severity of Assignment
Every defect identified in the system will have a different level of importance and impact. Some defects are blockers that can have a huge impact while others may cause less of a problem. It is the testers’ and the reporters’ responsibility to understand and assign a severity level to each defect. A defect with high or critical severity is usually given priority all other defects since major defects can impact the overall working of the software.
Assigning to a Developer
A reported defect that has not been assigned to anyone, has not been addressed, so to enable a defect to be worked upon, it must be given an assignee. With a large project having multiple modules and several developers, sometimes it is confusing to understand who, from the development side, must be assigned the defect. In such case, defects must be assigned to the development coordinator by testers, then internally the defects can be assigned to the correct developers. Assigning is generally not an issue when the defect is reported initially, but it becomes more relevant when a defect is reopened. Many a time, testers change a status and reopen a defect but forget to change the assignee. Similarly, if a defect has been fixed, it must be assigned back to the reporter for retesting.
Platform and OS Details
With the growing need for software to be cross-browser compatible and mobile friendly, it has become imperative for testers to include these environment details while reporting an issue. A defect reported by a tester can be marked as non-reproducible by the developers. Although not common, we do see this scenario occur in most of our development projects, and the root cause is often tied to the environment and platform used for QA. The testing team identifies an issue on a specific browser which the developers won’t be able to find out on their own. The developers mainly verify things on the primary browser; thus the testers must provide details about the platform and browser version used during QA so that it becomes easy to replicate. There are several defect reporting tools which capture the platform and OS details automatically, but there are instances where this information is not recorded. In such cases, actively provide information on the browser, OS version, etc. in the defects.
Defect Status
Status is another significant aspect to be taken care of while reporting a defect. A defect status, in turn, indicates the team’s responsibility. A defect with the status of open suggests that no action has been taken yet, and the developers are responsible for acknowledging and providing an update, whereas a status of fixed indicates that it is ready for QA. When a tester is asked to retest a defect, the tester uses the status filter to identify which defects are fixed and ready for
the retest. Different organizations follow different status specifications, but ultimately this is the attribute which indicates the actual state of the defect such as requires a fix, ready for validation, reopened, or ready for closure.
Conclusion
A good defect report must include the problem well illustrated and explained, along with detailed steps for recreating the issue and enough information for it to be easily assigned to the right person.
