QA Fundamentals: Creating High Quality of Bug Reporting
1. QA and its role in the software development life cycle
QA (Quality Assurance) is a part of a software development life cycle. Like its name, QA has the main function to ensure the quality of the product is already meet the company’s standard.
The main responsibility of the QA is to do a product testing based on the requirement that is already made on the initial development phase. The QA must report all the defects or bugs to the developer, so the developer can do the fixing later.
This bug reporting will be kept doing by the QA until the product under test is good enough to be released to the end-user or to the market.
2. The importance of creating a high quality of bug report
Since the main responsibility of QA is the bug reporting, then the QA ability to create a high quality of bug report is important. With the high quality of the bug report, then hopefully the developer team can quickly understand the bug that is being reported and can do the necessary fixing as soon as possible.
The quality of the bug report has no relation to the bug severity or the bug priority
One thing we need to understand that the quality of the bug report has no relation to the bug severity or the bug priority. The high quality of the bug report means it must be clear, complete, and straight to the point. It must describe the bug itself, so the developer team or anyone else who reads the bug report can quickly understand the issue without the need to ask again to the bug reporter. So, it is hoped that the time can be used more efficiently.
What will be happened if the QA create a bug report with the low quality? If the QA creates an unclear or incomplete bug report, then there is a big chance that the developer who read the bug report will do the fixing on the incorrect part. And once the developer releases the new version of the application to the QA environment in order to do the bug verification by the QA, then the QA will realize that the bug actually hasn’t fixed yet and QA must send back the bug report to the developer team, saying that the bug isn’t fixed yet.
This case surely will waste the valuable time, because the bug should be able to be fixed on a single release if the QA created the high quality of bug report earlier.
3. The main components that need to be present on the high quality of bug report
To create a high quality of bug report, each QA on the different companies could have their own standard. But the following components are the least must be present on the high quality of bug report.
Let’s see what is the point of the high quality of bug report.
a. Bug Title
Bug Title is the first part that will be read when a developer read the bug report. The good bug title is not too long and wordy, but it can represent the bug itself on the single sentence of the title.
Bug title can be started with a certain prefix. This prefix is optional depend on the needs, usually shows the location or the environment where the bug occurs, so make the developer easier to understand the bug report by reading its title only.
Example of a good bug title:
[iOS][iPhone 8][Product Detail]: Nothing happened when the user tap the “Buy” button
Short explanation:
There are 3 kinds of prefix given on that bug title:
· “iOS”: Indicates that the bug only occurs on the iOS build (doesn’t occur on Android build)
· “iPhone 8”: Indicates that the bug only occurs on the iPhone 8 device (doesn’t occur on the other iOS devices)
· “Product Detail”: Indicates the location where the bug occurs, which is on the “Product Detail” page
After the Prefix, then will be followed by the sentence that shows the bug itself. The sentence should be as short as possible, not too wordy, but directly show the bug clearly.
Example of a bad bug title:
There is an error on the Buy button
Short Explanation:
On that bug title, it didn’t mention the location of the bug, and it didn’t clearly show what kind of error that occurs.
The example above is just an example of how to create a good bug title. But it all depends on your own project requirements.
b. Bug Description
Bug description is the part where the QA can write down the all necessary information related to the bug. However, there are main parts that at least need to exist inside the bug description:
· Before the bug: This part is describing the activity that the user has done right before the bug occurs. This information can help the developer to track the root cause of the bug itself.
· The Bug itself: This part describing the detail issue that happened.
· After the Bug: After the bug occurs, what are the consequences and the effect on the user? Are there any other impacts that might be happened after the bug occurs?
Example of a Good Bug Description:
The user opens the app and login properly using iPhone 8 device. After successfully logged in, the user navigates to the electronic category and opens the first item shown on the product list. Once the product detail is opened, the user is attempted to tap the “Buy” button but notice that nothing happened when the “Buy” button is tapped. Because of this issue, the user unable to perform item purchase from the marketplace.
Short Explanation:
· Before the Bug: The user opens the app and login properly using iPhone 8 device. After successfully logged in, the user navigates to the electronic category and opens the first item shown on the product list. Once the product detail is opened, the user is attempted to tap the “Buy” button
· The Bug Itself: Notice that nothing happened when the “Buy” button is tapped.
· After the Bug: Because of this issue, the user unable to perform item purchases from the marketplace.
c. Expected Result
This section describing the expected result. The right expected result usually can be found in the requirement document.
But there are times where the expected result is not written anywhere in the requirement document. In this case, QA can write down what is the suggestion that should be happened as the expected result based on the QA common sense.
But if the QA is not sure, then it can be discussed with the Product Owner, Project Manager, or with the Business Analyst.
Example of Expected Result:
After tapping the “Buy” button, the screen should be redirected to the payment section.
d. Reproduction Step
QA should write down all the needed steps to reproduce the bug, from the very start that the user does until the bug occurs.
Example of a Good Reproduction Step:
1. Launch the app using iPhone 8 device
2. Log in to the app
3. Navigate to the electronic category
4. Tap on the first item shown on the product list
5. On the product detail page, tap on the “Buy” button
e. Reproducibility Rate
This is to show the percentage of bugs that occur in the number of attempts. When QA finds an issue, then the needed information is how many times that issue occurs on how many times attempts.
Example of Reproducibility Rate:
This bug occurs 5 times out of 5 attempts (5/5).
The example above means the bugs Reproducibility Rate is 100% (it always occurs on every attempt).
f. Bug Severity
Bug severity is the degree of impact that a bug has on the system.
Commonly, bug severity can be categorized into some levels:
· Critical: A bug that impacts the main functionality of the system. Might lead to the system crash, data loss, and massively affect the user experience. The testing progress also might be stopped because of this kind of bug.
· Major: A bug that still impacts the main functionality of the system, but it still has a workaround to avoid the bug, so the testing progress isn’t stopped.
· Medium: This bug doesn’t impact the main functionality of the system, but that could potentially reduce the user experience and can make some non-main functionality didn’t work.
· Minor: This bug has no related to the main functionality of the system. This still an issue, but even when this issue is ignored and doesn’t fix, it will not hinder the main functionality of the system.
· Usability: This more like a suggestion from QA in order to create better functionality of the system. This is actually not a bug, but when the developer does the fixing of this kind of issue, it can increase the user-experience.
Several categories above could be different among the companies, depend on their own system development process. QA should able to set this bug severity on their own based on their common sense.
g. Bug Priority
Bug priority is the urgency level from the developer side, when do they have to fix that bug, regardless of the severity of the bug itself.
Bug priority will be set by the QA at first, but in the end, will be decided by the Product Manager or by the client directly.
Commonly, bug priority can be divided into some levels:
· High: The top priority of the fixing by the developer. Need to be fixed as soon as possible.
· Medium: Will be deal by the developer after all high priority bugs are fixed
· Low: Latest priority of the fixing. Will be deal after high or medium priority bugs are fixed.
h. Evidence
A bug can be said as 100% valid when it accompanied by the evidence. Evidence can be a screenshot or video recording (maybe both), depend on the nature of the bug.
But need to be remembered that the evidence must be as short as possible, but clearly show the bug.
Besides screenshot or video recording, a log file also needs to be included when the QA submits a crash-type of bug. The logfile can help the developer to do the trace about the cause of the issue and when the crash issue has occurred on the system.
i. Other Notes (optional)
Depend on the project type, there is also some helpful information that a QA can include on the bug report to make it easier by the developer to understand the issue.
Some of the examples are:
· Device: Information about the device used for the testing, also the operating system that is being used. Example:
o Desktop PC with Windows 10–64 bit
o Samsung Galaxy S20 with Android 10, etc
· Application Version: When the application under test has a release version, it should be included in the bug report.
· Environment: QA usually will do the test on the QA environment. But there will be a time that the bug occurred on the production environment and doesn’t occur in the QA environment. In this case, QA can put the environment information on the bug report.
· Credential: When the steps to reproduce the bug require the user to log in using the specific credentials, then the QA must include this credential information used to log in to the system in the bug report. This can make the developer easier to reproduce the issue.
4. Before submitting a bug report
There are other few simple things that QA also must do in order to maintain the high quality of bug report:
a. Avoid duplicate
The first thing that needs to be done before QA submitting a bug report is to do the check on the bug database, to see if the bug is already submitted by another QA or not. This is to avoid duplication of the bug report. Duplicate bug reports will only waste QA time.
b. Check the documentation, check the test scope and known issue
Another basic thing that needs to be done before submitting a bug report is to check the project documentation and requirement that usually will be given on the project initiation phase.
Also pay attention to the test scope, so QA just needs to do the test on the right part of the system. Because if the QA is doing the test out of the decided scope, it will be ignored by the developer and will not be fixed. Again, this will only waste QA time.
QA can (usually) also find the known issue on the documentation. So, QA doesn’t need to report the bugs that are listed on the known issue section because it will also be ignored by the developer as well.
Thank you so much for reading my article. I hope this article helps your job.
