Bug report or bug report in software testing?
Let’s say this situation when you found a bug in some software and you immediately get a question what to do with it.
Of course, you can go to the developer and talk about the bug and describe on fingers how to reproduce it, but this is bad practice since the software developer can sit in another room, office or even in another country and the number of bugs can be so great that you can not remember them and then miss out.
And if you distract the developer for each petty bug and if they accumulate, then it doesn’t happen at all kosher that a loss of time and separation from the developer’s tasks is not the best solution.
Therefore, an adequate solution arises by itself - documenting the bugs found with the possibility of sharing them. Usually in it companies bugs are documented in bug-tracking systems.
There are many different bug-tracking systems that allow us not only to create tasks, change their statuses, but also create bug reports. The most common today are Redmine, Bugzilla, Mantis, JIRA
An example of what the list of bug reports looks like in JIRA:
Let's look at a common question at interviews, which fields should be filled in the bug report and which generally exist? The answer to this question is that the number of fields can be completely different from company to company. But at the same time, there are generally accepted most commonly used fields that you need to fill out when starting a bug.
Click here to learn more about software testing services
The essence of our bug is that we cannot log in to the admin panel with the admin user that was just created, therefore, all new admins cannot log in when you enter the correct user and password in the text fields. Below are explanations and descriptions of each of the fields.
For example, “Newly-created Admin user can't sign in to admin panel”,
that is, the description of the bug should be such that the programmer could not even open it and immediately look for the bug. But more often there are still complex bugs that require a description within additional actions and explanations of how to reproduce it and how it should actually be, so it’s difficult to describe only by summary. Therefore, the following fields exist:
For example, if the essence of the bug is that the admin cannot log in to the admin panel with the correct data, BUT only newly created ones can log in, that is, the old admins log in as usual and everything is ok.
Then you should write in this field that you need to create a new admin user.
Since the steps to create this admin are not the essence of this bug, this action can be moved to this field.
For example
1) Open login page of admin panel
2) Enter valid credentials into “Username” and “Password” text fields
3) Press Enter button
That is, this field describes the detailed steps until the moment we see the bug
After the last step we should see the result which is a bug in this situation
For example, it can be described as follows:
"You have entered incorrect user or password" message is displayed on login page
From the first try it seems why the field is well and everything is obvious, but there are very complex bugs in which everything seems to work, but whose behavior does not correspond to the behavior that is stated in the requirements or verbally from the words of the product partner. Therefore, the field is important and necessary for filling
If you have more than 1 project in your company, just select your project in which a bug was found
These priorities are distinguished:
High: Highest, highest priority
Medium: Medium priority
Low: Most last significance
Blocker: Set if a bug blocks the further operation of the application or blocks further testing, for example, such a bug that if you create a user with an existing name, then no user from the whole system can log in as the SQL error is displayed on main page and you can’t go anywhere else.
Critical: To be installed with a significant impact on the behavior of the software and incorrect behavior of the program, but not blocking the application, for example, a bug such that the floor The user can log in without entering the Major password
:Put with a slight impact on the behavior of the software, and non-critical for our project, for example, such a bug that if the number of entries in the list of entries is calculated incorrectly
Minor: Set if the effect on the functionality and behavior of the software does not produce a bug, for example, it may be a grammatical error in the name something
Comments
In the comments, you can indicate that the bug has been checked and indicate in which build it was checked.
You can also ask questions, assyna on the product update, clarifying some controversial points or details of the implementation or bug fix
Of course, you can go to the developer and talk about the bug and describe on fingers how to reproduce it, but this is bad practice since the software developer can sit in another room, office or even in another country and the number of bugs can be so great that you can not remember them and then miss out.
And if you distract the developer for each petty bug and if they accumulate, then it doesn’t happen at all kosher that a loss of time and separation from the developer’s tasks is not the best solution.
Therefore, an adequate solution arises by itself - documenting the bugs found with the possibility of sharing them. Usually in it companies bugs are documented in bug-tracking systems.
There are many different bug-tracking systems that allow us not only to create tasks, change their statuses, but also create bug reports. The most common today are Redmine, Bugzilla, Mantis, JIRA
An example of what the list of bug reports looks like in JIRA:
Let's look at a common question at interviews, which fields should be filled in the bug report and which generally exist? The answer to this question is that the number of fields can be completely different from company to company. But at the same time, there are generally accepted most commonly used fields that you need to fill out when starting a bug.
Click here to learn more about software testing services
The essence of our bug is that we cannot log in to the admin panel with the admin user that was just created, therefore, all new admins cannot log in when you enter the correct user and password in the text fields. Below are explanations and descriptions of each of the fields.
Main Fields in Bag Report
ID
This is the unique identifier of the bug found.Summary
A short and concise description of the bug answering the question What happened and under what conditions.For example, “Newly-created Admin user can't sign in to admin panel”,
that is, the description of the bug should be such that the programmer could not even open it and immediately look for the bug. But more often there are still complex bugs that require a description within additional actions and explanations of how to reproduce it and how it should actually be, so it’s difficult to describe only by summary. Therefore, the following fields exist:
Preconditions
It usually says what you need to do before completing our playback steps. Perhaps you need to create a special structure or users with different roles or templates needed to play this bug.For example, if the essence of the bug is that the admin cannot log in to the admin panel with the correct data, BUT only newly created ones can log in, that is, the old admins log in as usual and everything is ok.
Then you should write in this field that you need to create a new admin user.
Since the steps to create this admin are not the essence of this bug, this action can be moved to this field.
Steps to reproduce
The field is used to describe the playback steps at which our bug is played.For example
1) Open login page of admin panel
2) Enter valid credentials into “Username” and “Password” text fields
3) Press Enter button
That is, this field describes the detailed steps until the moment we see the bug
After the last step we should see the result which is a bug in this situation
Actual Result
Here we describe what we got at the last step, going through all the steps.For example, it can be described as follows:
"You have entered incorrect user or password" message is displayed on login page
Expected Result
In this field they write what should be how the software should behave in the last step of the steps.From the first try it seems why the field is well and everything is obvious, but there are very complex bugs in which everything seems to work, but whose behavior does not correspond to the behavior that is stated in the requirements or verbally from the words of the product partner. Therefore, the field is important and necessary for filling
Project
This is a scrolling list with project names.If you have more than 1 project in your company, just select your project in which a bug was found
Build number
It's no secret that the software has build or build numbers, and the behavior in one build may differ from the behavior in another, for this you need to clarify in which build the bug was found, maybe the bug has already been detected by the developer and was fixed in the next build, but you until you know about it, this also happensPriority
This field is used to determine the priority of the bug, usually the project is set by the manager or the scrum master, thus determining the priority of fixing the bug against the background of other bugs found, thus conducting the priority of fixing bugs.These priorities are distinguished:
High: Highest, highest priority
Medium: Medium priority
Low: Most last significance
Severity
This field indicates the severity of the error. There are several levels of error severity such as:Blocker: Set if a bug blocks the further operation of the application or blocks further testing, for example, such a bug that if you create a user with an existing name, then no user from the whole system can log in as the SQL error is displayed on main page and you can’t go anywhere else.
Critical: To be installed with a significant impact on the behavior of the software and incorrect behavior of the program, but not blocking the application, for example, a bug such that the floor The user can log in without entering the Major password
:Put with a slight impact on the behavior of the software, and non-critical for our project, for example, such a bug that if the number of entries in the list of entries is calculated incorrectly
Minor: Set if the effect on the functionality and behavior of the software does not produce a bug, for example, it may be a grammatical error in the name something
Assignee
Here you select the programmer who will fix the bug, and the field may not be available as the project manager decides which of the developers to send it based on the workload of the developers and the severity of the bugReporter
Usually filled automatically by the name of the person who creates the bug reportStatus
The status field is automatically filled in open, then it can be changed by the developer, tester or project manager, depending on what stage our bug is at. The figure shows the possible statuses:Comments
In the comments, you can indicate that the bug has been checked and indicate in which build it was checked.
You can also ask questions, assyna on the product update, clarifying some controversial points or details of the implementation or bug fix
Comments
Post a Comment