Effective defect reporting is crucial for software quality. It involves clearly documenting issues with objective language, focusing on expected vs. actual behavior and detailed reproduction steps. Reporting defects early significantly reduces costs, and each defect should have its own ticket for clear tracking.
The ability to report defects is one of the most vital pieces in the tester’s toolbox in terms of competencies. It is the item that will be tracked from its creation, through to triage, development, QA, all the way through to closure. It is an auditable item, but its main purpose is to highlight an issue to be resolved at a certain point in the future (or be on a backlog). This is something that, without being raised internally by QA, could have escaped into production, where the cost of such a report is exponentially higher than if it were located internally.
This is no surprise to anyone who participates in software development.
The following graph (Adapted from Griffiths, Mike 2015) shows the cost involved with detecting and reporting defects:
Figure 1
The earlier the defect is detected in the process, the cheaper it is to fix. From here, the cost involved when it's in Maintenance (which is likely to be found by an end user) is exponentially higher than if it were located during Design. This is due to the teams involved in handling the support calls, the triage meetings to establish priority, and the development team that resolves the issue.
Audience
When raising an issue to be resolved, it's crucial to maintain awareness, particularly as the person tasked to resolve the issue may be the same individual who developed the code originally. This situation can evoke a sense of vulnerability as the work essentially becomes an extension of the developer's identity. Consequently, the process of addressing issues can inadvertently feel like a personal critique rather than an assessment of the work product itself.
It's essential to emphasize this distinction to all parties involved, especially when documenting the issue in an official defect report. Objective language focusing solely on the characteristics and functionality of the product should be employed, avoiding any references to the author or developer. By doing so, the focus remains squarely on improving the product's quality rather than attributing fault or scrutinizing individual contributions. This approach fosters a collaborative and constructive environment conducive to effective issue resolution and continuous improvement.
House Concept
When reviewing house insurance, it is always in 2 parts: Buildings and Contents.
The same theory can be applied to that of a defect: Framework (Buildings) and Contents.
The building would be everything that forms part of the framework of the defect, such as:
The Contents are the crux of the issue, such as
How to Approach the Reporting of the Contents of the Defect
When reporting defects, I adhere to a mindset that assumes the target audience possesses no prior knowledge of the product, thus eliminating any preconceived assumptions. This approach ensures that the defect report is comprehensible to anyone, regardless of their familiarity with the product, while still encompassing all pertinent details.
In crafting the defect report, clarity is paramount. Each aspect must be presented in a manner that is easily digestible and understandable by a diverse audience. At the same time, it's crucial to include all relevant details necessary for effectively diagnosing and addressing the issue at hand.
Expected Behaviour
This is the expectation that the reporter has around the behaviour, regardless of whether this was included in any requirements or user story.
There needs to be no ambiguity in the expectation stated. During the triage process, the decision may be to defer the issue for future releases, further exploration required or accept it in its current guise.
Actual Behaviour
This is the behaviour that is observed. Often, it is the opposite of what's detailed in the expectation.
It is really useful in this part to include anything that would assist those who will be assigned to resolve it. These could be items such as:
Steps to Recreate
These are the steps from start to finish that result in the actual behaviour.
For example, let’s assume there is an issue with loading a search item (“software testing”) from google.co.uk, which results in a 404 page error.
The crux of the issue would look like this:
EXPECTED BEHAVIOUR - After searching for the term “software testing” on google.co.uk, it directs the user to a relevant page when the link is clicked.
ACTUAL BEHAVIOUR - After searching for the item “software testing” on google.co.uk, it directs the user to a 404 page error.
STEPS TO RECREATE
1. Navigate to the following URL www.google.co.uk on any browser
2. Click on the [Search] field and type “software testing”
3. Click on the top result from the search (i.e., software testing on Wikipedia)
This results in a 404 page error.
1:1 Ratio to Issue per Defect/Bug Ticket
As tempting as it may be to include a list of defects within one ticket, there are reasons why it’s regarded as bad practice.
Having one issue per ticket makes the ticket self-contained. It is clear regarding the status that when the issue is resolved and has been re-tested by QA, the status can be updated to the next stage of the workflow (i.e., passed QA, defect closed, etc).
Once you include multiple issues within a ticket, the status could remain dormant, despite activity to resolve some of the issues listed within it.
Status can incorrectly be assigned back to QA. This is the case when some issues may have been accidentally missed during the investigation. The summary of this will be sent back to development and will cause an extra time delay.
Defect Raised—What’s next?
There is a balance to strike about what to do once a defect is raised between professionally caring about what (if anything) is happening with the issue to letting the defect go and moving on. The truth is, you don’t want to be camped on either side. You need to move on to your next piece of work and apply the appropriate focus, but it’s worth setting a reminder for some point in the future where you can check what is happening with the issue. Usually, the defects will be triaged by representatives from different departments who may prioritise the ticket for a release into the future, and it will be acknowledged. At least keeping tabs on the issue reduces the risk of dormant open tickets that clog up the Jira system.
For Further Information
Lets Hang!