Testers perform Testing on Application Under Test (AUT) to find defects in it and need to log or raise defect in a defect management tool E.g. JIRA, HPALM etc. A defect management tool is used to keep track of progress made on a defect through different stages.
While logging a defect, you must need to provide all necessary details about a defect so that any one in team can clearly understand the defect. If we do not provide all necessary details, developers might mark defect as not reproducible or rejected. In this post, I will explain what we must include while logging a defect.
Almost all defect tracking tools show you multiple fields to fill up while logging a bug. Fields can be added/removed/modified by admin team. Generally project manager makes required fields as mandatory so that you do not miss any mandatory fields while raising a bug. We will see some of mandatory fields of a defect below:
- Project Name: It is a mandatory field. You might or might not be working on multiple projects. If you are using a tool, it will list out all the projects and by default some projects will be shown as selected. In this case, you must need to select proper project name to raise a defect for correct project.
- Module Name:It is a mandatory field. A project are divided in to multiple modules based on functionalities. You must need to provide module name while logging a bug. You can notice first two details i.e. Project Name and Module Name say which part of application has this defect. You can relate it with real time example as : Flat no D-204( Module Name) in Casagrand Royce Society (Project Name).
- Sub Module Name: It may be optional field and completely depends on project manager. If your module is big and it is further divided in small sub modules, you may need to fill this field.
- Title/Summary : It is a mandatory field. You need to provide short and self descriptive lines about defect. It must not be lengthy. It should be to the point. For example: You are not able to login to application with valid credentials. You can raise a defect with title “Unable to access application with valid credentials”.
- Environment Name: Testing team need to test application in multiple environments. You must specify in which environment defect is found.
- Build Id : Developers provides multiple builds with different set of requirements or merged requirements. You must need to specify build number in which defect was found so that developers can try to replicate bug in same code base.
- Description/Steps To Reproduce: It is most important field for raising a bug. You must provide proper steps to reproduce the defect. It should be so clear so that any one should be able to read and understand it easily. If you provide steps clearly , it wastes a lot of time as it might back assigned to you and you need to assigned again after modifying steps. Wrong or incomplete steps may lead to wrong understanding by developers. You should also provide browser name and version, operating system details etc.
- Test Data: You should provide the data used for testing application and encountered a defect. Generally A data driven application has data dependent defects. So you should provide test data while logging defect so that developer can start looking for root cause of defect effectively.
- Severity: It is also a mandatory field. You need to provide the criticality of a defect. Based on severity, developer decide priority of defect. You can learn about severity in this post.
- Assignee: You must need to assign bug to appropriate team or lead or manager to let them know that you have raise a bug and they need to work on that. A mail is triggered when you choose a assignee.
- Link to requirement: You should link defect to proper requirement or story. It helps in identifying to which requirement or story defects belongs. It is also useful to find defect prone functionality if defects are more.
- Expected Result and Actual Result: You need to provide how you conclude that it is defect. What you were expecting and what you got. These details can be provided in Description it self but again depends on your process decided by manager or organisation.
- Defect Proofs: Proofs are mandatory. You must attach screenshot or request response or anything which confirm it is a defect or actual result is not as per expected. You can also make a gif or videos which will be more useful.
- Some fields like Created By, Creation Date, Status , Defect ID etc are auto filled by the tool itself. If you are not using any tool, you must include these details.
You must be very precise while raising a defect. Do not provide confusing description. It is also advisable to confirm defect by reproducing more than one time and confirm against requirement document.
If you have any doubt, feel free to comment below.
If you like my posts, please like, comment, share and subscribe.
#ThanksForReading
#HappyTesting