What good defect report should contain

If you read my blog, chances are you’ve either written a defect report or come across an example. The importance of defect reports often surfaces in interviews, underscoring their significance in maintaining effective communication within a team and expediting project timelines.

In today’s post, I aim to:

• Define the characteristics of a well-crafted defect report
• Outline the essential components of an effective defect report
• Offer tips for crafting a high-quality defect report
• Highlight the advantages of preparing thorough defect reports
• Sum up with a conclusion on the topic.”

What a good defect report is

Numerous articles discuss crafting effective bug reports, yet what often goes unnoticed is that, in many instances, we are reporting defects. Throughout the handling of a defect report, a determination is made as to whether the anomaly is indeed a genuine defect or something else.

ISTQB foundation Level Syllabus says:

‘Since one of the major test objectives is to find defects, an established defect management process is essential. Although we refer to “defects” here, the reported anomalies may turn out to be real defects or something else (e.g., false positive, change request) – this is resolved during the process of dealing with the defect reports.’ [1]

The term ‘bug report’ is commonly used in organisations, but for precision, let’s adhere to the term ‘defect report’.

In almost all cases, a defect report serves as written communication for the team when anomalies arise in the product under development, be it in documentation or the actual software. While I intended to touch on verbal defect reports, even in scenarios of pair testing with a programmer post-release, reporting every noticed defect remains essential. This practise is rooted in the need to maintain a historical record of our actions, as even the slightest issue can escalate into more significant problems down the line.

The primary purpose of a defect report is to pinpoint anomalies in the project and communicate them to the team, particularly the developers. A well-crafted defect report must boast a tidy structure, be composed with politeness, articulate language, and incorporate as many crucial details as possible. When a defect report is well-written, developers can comprehend the issue without a barrage of questions and proceed to address it promptly. This clarity extends to other team members, ensuring everyone understands the nature of the problem. In essence, the ultimate goal of a well-executed defect report is to effectively communicate the identified defect to the entire team.

What good defect report should contain

I regret I have not created the count of how many defect reports I have created in my more than 10 years of testing journey, but I bet thousands. The thing that was always helpful was to have a prepared template for the report. It contained just the sections, but was very useful to not forget about anything when creating it under the pressure. Developers were used to the structure of the report, so that was beneficial to them as well. But lets discuss what actually good report should contain. What are the most beneficial information.

Defect ID

If we use tools like Jira, the unique ID will be given automatically. It helps identify the reports.

Title/Summary

Keep it brief and informative. Provide a concise description of the problem; this doesn’t just aid developers, but a specific title facilitates the Product Owner in assigning the report to the right developer, expediting the process as the correct programmer can promptly address it.

Another crucial point worth mentioning is from my past job where we held weekly demos showcasing the team’s current projects. Despite the brevity of these sessions, we routinely reviewed the list of resolved bugs. A well-crafted summary proved highly beneficial during these demos, allowing the team to grasp what had been fixed without delving into the content of each bug. The list of titles alone proved sufficient, saving considerable time and enhancing the efficiency of these sessions.

Example of an ineffective title:

‘Login page does not work. It was working fine yesterday. Fix it.’

• lacks specificity about the problem
• vague in its description
• issues a directive to fix without clarifying the problem; it might not be a real issue, or it could be categorised as a change request
• fails to foster good communication and collaboration among testers, developers, and the rest of the team

Example of an effective title:

‘Login page: Username textbox is not getting active when I click on it’

• highly informative; readers grasp the problem without delving into the summary
• aids developers in promptly addressing the issue
• allows the product owner to assign the problem to the appropriate team member

Environment

A crucial aspect to include; it must provide details about the environment where the issue occurred. Since problems can be specific to a particular environment, omitting this point is not advisable. Examples of environment details include:

• Operating system: Specify the name and version.
• Device information: Include the manufacturer and model.
• Browser details: Mention the name and version.
• Network connectivity: Indicate whether it’s through wifi or another connection.
• Application version: Specify the version used.

Include all relevant information that you believe developers might find valuable during the debugging process.

Summary

A comprehensive depiction of the problem. While not as concise as the title, it should encompass crucial and valuable information aiding in reproducing and rectifying the issue. Consider including details such as the frequency of the defect occurrence – whether it happens every time, intermittently, or occasionally. In certain instances, particularly in tools like Jira, the Summary may also feature steps to reproduce the issue, along with the actual and expected results.

Steps to reproduce

Describe the entire path of how to recreate the issue. Each step should be placed in a separate line. It is important to be specific, but also remember who will be reading it. There is no need to add obvious points like open the application, log in to the system.

Example:

1. Go to the login page

2. Click inside ‘username’ text box

Expected Results

The anticipated outcome is a description of the desired result for a feature or function, detailing what should occur in the absence of any defects. Determined by technical specifications, customer requirements, or the tester’s perspective, expected results draw from various sources:

Technical specifications: Derived from documentation, team discussions during events like sprint planning or standups, and design considerations. These resources ensure that testers and team members comprehend how the software and its functionalities are intended to function.

Customer needs: Keeping the end user in mind is crucial for all team members. Understanding the associated risks, especially in sectors like health, space, or banking, is imperative. Neglecting defects in such software could lead to severe consequences, such as illness or substantial losses. While this doesn’t diminish the importance of other software types, it underscores the need to evaluate risks and align with customer expectations.

Tester’s opinion: Testers play a pivotal role in delivering a quality product that aligns with client expectations and uncovering as many defects as possible. Leveraging their deep understanding of the product, including its weak points, and drawing from experience and common sense, testers often identify issues not immediately apparent to other team members. Throughout a project, effective communication fosters trust within the team, ensuring that testers’ insights are valued and contribute to preventing serious issues from reaching production.

Actual Results

This section delineates the real impact of the issue. The defect reporter should be precise, specific, and informative, avoiding lengthy essays, as developers are pressed for time. Here, the focus is on providing details of the actual occurrence without suggesting solutions or assigning blame for the defect. Our role is to offer accurate and pertinent information, aiding the person tasked with investigating and resolving the issue to commence work promptly.

Severity

ISTQB Syllabus says ‘Severity of the defect (degree of impact) on the interests of stakeholders or requirements’[2] Following levels are commonly used in this field:

Low – minimal impact on the application/functionality. These issues typically pertain to the UI, such as incorrect button size or colour.

Minor – defects that do not affect fundamental functions, like a missing space in a specific location.

Major – these defects have a significant adverse impact on a large area of the system, for instance, a missing footer on a webpage.

Critical – defects causing key functionalities to fail, or those related to security breaches or data leaks.

Blocker – the application crashes, preventing further testing until the issue is resolved.

Priority

How urgently the defect requires attention and resolution. This field is crucial as it guides developers on the order in which defects should be addressed.

Priority can be classified as:

Minor – typos, missing icons, etc.

Medium – anything impacting user experience negatively.

High – anything significantly affecting user flow or causing the application to crash.

In my experience, both priority and severity were often deliberated and decided upon by the entire team during planning sessions. High severity or/and high priority defects were exceptions and required immediate fixing. Exploring different perspectives on defects during these discussions was enlightening, providing diverse insights that helped the entire team comprehend the product and identify its weak points.

When developers or other team members assess the defect, they should take into account a combination of Priority and Severity. Let me illustrate this with examples:

High priority, high severity – Requires an immediate fix as the application has crashed, rendering it unusable for users.

High priority, low severity – Involves a spelling mistake on the home page in a critical area, such as the heading or title. It needs prompt attention but is a quick and easy fix.

Low priority, high severity – The app crashes when a user clicks a link, but this link is situated in an infrequently used area. While developers need some time to address it, it doesn’t demand an urgent fix.

Low priority, low severity – Encompasses a spelling mistake in an area seldom used in the application, indicating it doesn’t need an immediate fix. Additionally, it is a trivial defect to rectify.

Visual proof/screenshots/logs

This is a crucial and beneficial aspect. Regardless of how clearly something is described, visual evidence can always enhance the defect report. Screenshots, screen recordings, logs, etc., provide developers with a precise understanding of the situation. Based on my experience, well-captured screenshots and videos can significantly reduce the time developers spend on understanding and resolving issues.

Tips for Crafting Effective Defect Reports

Writing a comprehensive and articulate defect report is pivotal in the software testing process. Here are valuable tips to enhance the quality of your defect reports:

Single Defect per Report: Address each issue in a separate defect report. Avoid combining multiple problems in a single ticket to maintain clarity and focus.

Timely Reporting: Create defect reports promptly after discovering an issue. Timely reporting ensures that you capture all essential details and minimises the risk of overlooking critical information.

Seek Assistance: If uncertain about any aspect, don’t hesitate to seek help from team members. Collaboration fosters a shared goal, and seeking assistance can be more efficient than attempting to solve challenges independently.

Reproducibility: Reproduce the defect multiple times and review the report before saving it. This practise guarantees a high-quality report, providing developers with the necessary information for investigation and resolution.

Avoid Duplicates: In larger teams, preventing duplicate defect reports is crucial. Check the defect tracker to ensure your issue hasn’t already been reported, preventing unnecessary clutter.

Clarity and Simplicity: Be direct and keep the defect report simple. Use straightforward language to convey the issue clearly without unnecessary complexity.

Kindness in Reporting: Approach defect reporting with kindness. Understand that mistakes happen, and developers, like testers, are human. Communicate issues with care and avoid a confrontational tone.

Build Relationships: Foster positive relationships with team members. This is particularly valuable when urgently notifying the team of critical issues or discussing defect reports during planning sessions.

Solicit Feedback: Seek feedback from colleagues on your defect reports. Constructive feedback not only improves your reporting skills but also enhances team dynamics.

Avoid Haste: Resist the urge to rush when creating defect reports. While working under pressure, a poorly written report can lead to confusion for developers, wasting time and potentially causing future incidents. Take the time to create clear, detailed reports to facilitate efficient issue resolution and maintain strong collaboration between testers and developers.

Benefits of Crafting Effective Defect Reports

Creating high-quality defect reports offers several advantages in the software testing process:

Accelerated Issue Resolution: Clarity in defect reports expedites the fixing process, providing developers with precise details for investigation and resolution.

Positive Team Relations: Well-crafted reports contribute to positive relationships, especially with developers. Testers are perceived as integral team members working collaboratively towards common goals, rather than individuals solely focused on identifying faults and assigning blame.

Transparent Communication: Clear and well-structured reports, particularly in the title, convey transparent messages to all stakeholders. During demo sessions, stakeholders can easily review the list of addressed issues without delving into detailed descriptions, streamlining the communication process and enhancing overall project transparency.

Conclusion

While writing a defect report might appear straightforward, it is a nuanced and essential activity in the software testing process. A defect report serves as a vital means of communication among team members. The report should be crafted with both kindness and precision, striking a balance between maintaining a positive atmosphere and conveying crucial details. Each element discussed earlier plays a pivotal role and must be accurately filled in. Drawing from my own experiences, I found that adhering to the rules outlined above garnered appreciation from developers. By providing comprehensive details while maintaining a polite tone, defect reports contribute significantly to effective team collaboration and issue resolution.

If you want to know about software testing, defect management and good defect reporting have a look into our courses– especially ‘Introduction to Testing’

[1] ISTQB Certified Tester Foundation Level Syllabus v4.0 p.55

[2] ISTQB Certified Tester Foundation Level Syllabus v4.0 p.56