How to log a defect/bug with a detailed description etc

 



1. Assign a bug number

Each reported defect should have its unique ID number. It will enable identifying the issue by the responsible developer and fixing it as soon as possible. Remember that each bug should be reported separately and that their ID should not be confusing. If you’re using a dedicated defect management system, such numbers will be generated automatically. In the case of Jira, the ID number is called a Jira Issue Key and is specific to every reported bug.

2. Prepare the right title

The title of a defect, called also a summary, is a crucial element of the description. It should immediately indicate the area of function in which it occurred and the type of the bug. Thanks to this, the responsible developer will be clearly informed about the defect and will be able to react immediately. Writing a consistent summary is important especially in more complex projects in which there are multiple errors that need to be split into different bug categories.

3. Be specific

Providing general information about the issue will definitely not be enough. To ensure efficient reporting and the fast reaction of the responsible developers, a tester should provide as much specific information as it’s possible. 

Thus, remember to name the exact product, version, component, platform, and operating system in which the bug occurred. Describe the situation in which the bug was revealed, so the reader can understand and visualize it. In order to write an even more complete bug description, you can also check error logs for more details. Such an approach will help to avoid misunderstandings and wasting time asking around for explanations. 

 

4. Make it readable

Although the bug description has to include all the necessary details, no one expects essays. Try to describe the issue in a minimal number of words and focus only on facts, not opinions. Every sentence of the report should be simple, meaningful, clear, and consistent - this will accelerate the defect-fixing process. 

Moreover, remember to format your report. Use numeric lists and bullets, as they will make the report easily readable and clear-cut. Remember also to read it a few times before hitting the Submit button to make sure that everything will be obvious for the reader, and that your text will also be bug-free. 

5.Indicate severity and priority

The next thing that needs to be done when preparing a defect report is rating its severity and priority. Although all bugs need to be fixed, not all of them are equally important. For instance, defects interrupting the crucial functionalities of the software have to be fixed immediately, unlike the small text or graphical corrections. Each bug should also be categorized, so developers can immediately know the area of expected improvements. 

Bugs prioritization and categorization will help to organize work more smoothly. In order to ensure the top efficiency, we highly recommend using dedicated software equipped with a bug scoring system, such as Jira extended with RTM and most popular but also configurable defect categories.

6. Write steps to reproduce

When preparing a defect report, write down step by step what exactly is happening. Avoid using general phrases, such as “I can’t log in”. Describe exactly what happens when the error occurs, and what steps are leading to it. Mind that there might be a few ways to complete one action, so the more specific you will be, the better. Define who, what, where when and how you found the defect, so the developer could understand it and respond to the problem accurately.

7. Include expected results

A good bug description is not only about the problem itself. It should also include information about actual results vs expected results. Writing down what are the intended actions will help to identify the source of the problem and decide on what exactly needs to be fixed. 

When writing about the expected result, remember to apply the general and well-known rule - be as specific as possible.

8. Provide documentation

If only it’s possible, provide additional documentation of the detected bug. It can be a screenshot or a video in which the defect is visible. To explain the issue better, you can even attach a few files presenting what happens when the defect occurs. In the picture, you can also highlight the most important remarks. 

Such an approach will help the developer to understand the issue better. Of course, you can do it in a bug-reporting program that is equipped in a field in which you can attach additional files.  

9. Avoid commanding tone

The last but not least, remember to be empathetic when writing a bug report. Never use harsh words. Mistakes happen and are an integral part of software development. So, don’t blame your colleagues for the defects, even though it’s them who messed up. Such attitude only leads to an unhealthy work atmosphere. It’s not worth it! Instead of giving orders, try to write your report in a tone of request or suggestion. Believe us, this will sound much better. 


defects can and do have the following additional data fields:

  1. Reported by
  2. Date Reported
  3. Assigned to
  4. Status
  5. Module/Business Area

Large-scale teams use different kinds of defect management software to make this process easier and more efficient.

Some examples include:

  • JIRA
  • Bugzilla
  • TestRail
  • Micro Focus ALM
  • IBM Rational ClearQuest

Sample Bug/Defect Template with Example

Defect IDD_AppXYZ_Module1_001
Defect TitleManager Dashboard is not allowing adding newly reports types- history, work completion trends
Defect Description/Steps to reproduce1. Login in as a manager (include manager credentials only if not confidential)
2. Click on the dashboard
3. Click on + icon to add a new report
4. Select History/Work completion report trends report type
5. Click “Add to dashboard button”
Expected ResultThe new report should add and the manager should be able to view it on the dashboard
Actual ResultAn error with the message “No report exists with that name” error message shows
Evidence/attachment< Add image or a word doc with multiple images showing sequence of steps or a quick/short video >
SeverityHigh
PriorityMedium
Module affectedDashboards and Manager reporting
EnvironmentFireFox version 32.4
Reported byTester XYZ
Reported on03-02-2023
StatusNew
Assigned ToDeveloper ABC

Comments

Post a Comment

Popular posts from this blog

What are the different types of Non-Functional Tests

Image
Non Functional Testing Non-Functional Testing  is defined as a type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. Following are the most common  Types of Non Functional  Testing: Performance Testing Load Testing Failover Testing Compatibility Testing Usability Testing Stress Testing Maintainability Testing Scalability Testing Volume Testing Security Testing Disaster Recovery Testing Compliance Testing Portability Testing Efficiency Testing Reliability Testing Baseline Testing Endurance Testing Documentation Testing Recovery Testing Internationalization Testing Localization Testing 1) Security: The parameter defines how a system is safeguarded against deliberate and sudden attacks from internal and external sources. This is tested via Security Testing. 2) Reliability: The extent to which any software system continuously performs the specified functions without failure. This is tested by R...
Read more

What is CI, CD & CT?

Image
Continuous Integration (CT), continuous Testing (CT) and continuous Delivery (CD) accelerate the code release process and are thus crucial to DevOps. These processes are often referred to as a  CI/CD pipeline  or a  DevOps pipeline. Continuous integration.  In the CI stage, developers write a feature, update or fix, then commit the code to a central code repository. Organizations often use  version control tools  like GitHub and Atlassian Bitbucket. These tools enable developers to write or modify code without interrupting another developer's progress. Once the code commits to the repo, Continuous Testing (CT) begins to  shine. In the initial stage of the pipeline, static code analysis can check for syntax issues and common vulnerabilities. Use plugins in the CI server to configure static code analysis with a tool.  Static code analysis is an initial test of the code. If the code passes, the unit test stage comes next, unless these tests wer...
Read more

How to push changes to Git Hub using GIT GUI?

Image
Getting started with Git GUI Step 1: Create Remote Repository Now, we need a Git repository, and we’ll create a new remote repository on Github. Step 2: Create a Local Repository For creating a local repository: in our Git GUI, click on  “Create New Repository” . Select the location you wish to store your repository in. It is important to note that the selected repository location MUST NOT  exist. In order for this new repository to be initialized, you must first create a file, any file, in your local repo.Then, you must Commit and Push to the remote Git repository location. Step 3: Clone a Remote Repository to a Local Repository In order to clone a repository, click on the “ Clone Existing Repository ” link in the Git GUI window. An existing repository is one that is already initialized and/or has commits pushed to it. Note:  In the Source Location field, fill in the Git remote repository location. The target directory works as same in the case of creating a local reposi...
Read more