When you are working as part of a team of QA engineers the mission is simple: find and report bugs!
Who would want to let a defect escape their hands, or even after reporting a bug, find out that the team for that project determined it was an invalid bug? No one for sure!
When we talk about bugs, it's necessary to explain their meaning and how important their role is on a daily basis.
What is a bug?
When talking about bugs, we can refer to three terms according to the ISTQB:
Default: A malfunction that can cause the component or system to fail to perform its required function, for example: an incorrect statement or an incorrect definition of data. If a defect is found during execution, it can cause a component or system failure.
Failure: A human action that produces wrong results.
Error: Deviation in the expected delivery of the component or system.
Bug is the general term used to incorporate the terms reviewed previously. So we can say in a few words that a bug is everything that causes some type of dissatisfaction in us or in the client. On many occasions, the engineer's desire to report as many bugs as possible can even lead to an invalid report.
Experience makes the difference
Reviewing requirements
The information contained in the requirements is extremely important since it goes beyond its own acceptance criteria, therefore, understanding the entire requirement is a must to avoid leaving any scenario behind.
At the moment a bug is found, the actual behavior of the system may be compared with the expected one according to the specific requirement in order to determine if there is an inconsistency or not. This will greatly reduce the possibility of reporting mentioned bugs that could be found in some part of the requirement.
Is it the right environment?
When initiating tests on the product, you have to make certain that the environment in which the test will be carried out is the one intended for this purpose. There is a huge risk of reporting invalid bugs if a revision is not made in this regard since in the correct environment the functionalities could be operating correctly.
Clearing cache
When working on platforms or web environments and the browser cache is not deleted, the page usually loads what is already in the local memory, depriving the QA engineer of seeing new changes made to the application; making it easy to fall into the error of reporting non-existent bugs. To avoid this, you can browse in incognito mode or clean these temporary browser files periodically or each time you are going to start a test cycle. By applying the changes in this way, you can report bugs whose validity is indisputable.
Testing a Filter
With a tool like JIRA for example, used for reporting and tracking bugs, you have the possibility to create a filter to know which bugs have been marked as invalid. This will help you identify which cases are considered invalid and compare them to the case reported as a bug.
There are many different ways to keep control of this, there are even unconventional tools you can use for it, for example: Google Drive.
In addition, performing a search in the defect management tool regarding the error that should be reported is a good practice to avoid reporting duplicate bugs.
No Filters? There can always be communication
Communication is extremely important in a team, not only to know what each member is doing, but so that each quality engineer has knowledge about previously made reports; In this way, we will avoid reporting bugs that have already been reported by other members of the quality control team and that were already - at some point - marked as invalid due to existing reports prior to the current one. So, it is important to review the bugs that have already been reported.
All the above tips can help to avoid the reporting of invalid bugs, so applying them in daily activities of control and quality assurance will help to avoid overwork of both the QA team and the development team in order to optimize the time used for the reporting and correction of defects.
