Defect Identification and Reporting 101

Identifying and reporting defects are critical skills for a QA tester. Here are some tips for finding more defects and preparing accurate, helpful reports to get them resolved.

A large part of a QA tester’s job responsibility is identifying and reporting defects. Writing defect reports is a critical QA skill that requires the ability to describe with relevant detail the exact steps to reproduce the defect. A well-written defect must be understood by not only developers trying to find and fix the issue but also product and development managers who schedule when and where defects are fixed.

Creating a defect report that clearly describes the problem and the steps to find it is essential. Developers must understand clearly what the problem is as well as where it is to properly create a fix.

QA testers need to get creative and use investigative testing to find defects hidden below the UI surface. Expand your defect identification potential by testing beyond the happy path or expected results and testing deeper to find additional defects.

This guide provides information on testing techniques for identifying non-superficial defects, and tips for reporting defects accurately and understandably.

Key Takeaways

• What is investigative testing?
• Why is detailed information important for an accurate defect report?
• What are the important sections to include in a defect report?
• Discover how to leverage browser developer tools to find hidden defects.

What is Investigative Testing?

Investigative testing is using a variety of testing techniques to reveal defects in the UI or hidden behind the UI of an application. It’s a method of testing that requires creativity and a willingness to break applications. Investigative testers test to find defects rather than confirm functionality.

Testing techniques employed for investigative testing include:

• Creating a mind map around functional areas and test looking for integrations with databases, APIs and third-party software
• Testing application functionality beyond the expected result and try to break the application and trigger errors or crashes
• Testing for missing error messaging by finding errors that don’t inform the user or redirect users back to a working portion of the application
• Attempting to interrupt database or other backend processing
• Using invalid data, data types and work backward through the application
• Performing unexpected and unplanned actions

Mind mapping is a useful testing technique that allows a tester to flush out various application workflows and functional paths. Mind maps can be simple drawings and text on paper or done using a tool that creates a digital map. The purpose of a mind map is to write out all the possible workflows, steps or procedures within an application. Include configuration settings, customizable options and a variety of data types. Cover all possible scenarios.

Try to find scenarios outside the expected or happy path. Discover non-logical workflows through the application. For example, click buttons or links multiple times in rapid succession. Use the infamous back button on the browser and see how the application responds. Click like you haven’t clicked before, repeatedly and rapidly. Find out if the application can handle users clicking buttons in a variety of invalid patterns and at different speeds.

Investigative testing is easier the more experienced the tester is with an application or application group. Use your testing knowledge and experience with an application to find hidden defects in areas where code may be more complex and prone to defects.

Also, rely on your understanding of individual developer tendencies and habits. For example, some developers test their code first, while others do not. Many developers are careful reading user stories and requirement descriptions, others are in a hurry and often miss critical details. All the missed requirement details are likely defects or create defects further within the application.

Investigate application functionality around connectivity points. APIs, databases, messaging systems and third-party software are often used to send SMS and email notifications. Test around API connections and data requirements. See if you can alter an incoming transfer or create data that’s invalid to force an API failure. Investigate application steps that impact user documents and input forms. Find out if you can remove, change, overwrite or even delete data.

New code deployments offer a unique opportunity to test authentication and perform basic security tests. Test to confirm new users can be created and configured to various authentication levels. Test to find out if, when users have a role and authentication mismatch, are they still able to log in? Are they accessing the correct security level based on role and configuration settings? Dig in to find defects in unexpected or rarely tested places.

Tips for Leveraging Browser Developer Tools to Find Defects

If the applications you test run on a browser, you can leverage the tool’s logs to find defects that are hidden from displaying in the UI. Developer tools exist on all browsers and can be found typically under the tools or options menus. For example, the Chrome browser has a developer tool that consists of real-time logs for a variety of functions within an application.

Chrome developer tools create logs on several tabs including:

• Elements
• Console
• Sources
• Network
• Performance
• Memory
• Application
• Security

The Console, Network and Elements tabs are the most useful for QA testers. Each of these tabs runs logs for errors continuously. Each will display and indicate errors with some explanatory details as to cause and location. You’ll notice many of the errors never display in the application UI, but they are defects all the same.

The Elements tab can be used to drill into the code and investigate the properties of various application elements. Test to see if you can set an element to an invalid state and see how the application responds. For testers without log files generated by an application, the browser developer tools offer a valid opportunity to investigate and find hidden defects that don’t always display within the application UI.

Why is Detailed Information Important for an Accurate Defect Report?

Including specific, relevant and accurate details is essential for creating a clear understanding of a defect and how to generate it. The details hold the key for a developer trying to find and fix an issue effectively. Accurate details help developers understand what the issue is, where it may be in the code and how to fix it. After all, locating broken code lines in an often complex code base is not an easy task.

The only way to fix a bug correctly is by writing a defect report that is accurate, precise and detailed. Understand that when defect reports contain inaccuracies or are missing information, developers may not fully understand the problem. Either they’ll not fix it, or they’ll create a secondary defect by altering code unnecessarily.

Clarity and accuracy in defect reports are critical to helping developers maintain high-quality applications efficiently. Save your developers time and frustration by creating detailed and accurate defect reports.

What are the Important Sections to Include in a Defect Report?

A well-written defect report includes the following:

• Unique defect ID
• Defect reporter’s name and contact information
• Application name and version
• Test server or environment
• Browser and OS if applicable, include version numbers for both
• Reproducible set to Yes, No or Random
• Link to test case if applicable
• Screenshots, videos, log files or other relevant attachments
• Configuration settings used
• Steps to reproduce including expected result and actual result
• Severity or priority
• Troubleshooting notes

When writing a defect report never assume the reader understands the application functionality fully. Don’t skip steps or leave out configuration or setting details that impact the ability to reproduce the defect. Steps to reproduce must include actual and expected results as well as clear, specific and accurate step details.

For expected and actual results, include why the actual results are defective. Don’t leave it up to the reader to extract the defect. State why the defect is an issue. Add in your troubleshooting notes if applicable. Troubleshooting notes help developers understand what you’ve investigated and helps them identify the root cause instead of what may be a single symptom.

Attach log files, screenshots or videos when relevant to describing or explaining the defect. Files that don’t contribute to understanding and identifying a defect are noise. Leave it out if it doesn’t count. The clearer the communication in a defect report, the more likely the defect can be located and fixed efficiently and accurately.

Defect identification and reporting are core and critical functions of QA testing. Both contribute significantly to the quality of an application and the efficiency of a software development team. Go above and beyond by using investigative testing techniques to find more defects. Once you find defects, get them fixed the first time by creating clear, detailed and accurate defect reports.

Do you need a solid, quality codeless test automation tool for your development and QA teams? Prefer the simplicity of a cloud-based service? Create effective and efficient codeless test automation using Test Studio from Progress Telerik. Keep tests and teams productive with Test Studio.