
Typical Mistakes When Raising a Bug Issue

Here’s an essential part of the everyday Software testing procedure. When a Software Tester find a bug and prepare to raise and document the issue, it is important to follow the basics and focus on help solving the issue by reporting the team with facts and most importantly being neutral and don’t fall into the trap of being too personal to it.
Here’s a collection key points I like to keep in mind while carrying out tests for my clients based on my experience and colleagues I have worked with in the past.
Bug Issue Title
Pay attention to the title of a bug report. It should be a summary of the issue in a few words only.
Pay attention to the keywords related to the issue and where it was found and the causes in which leads to a defect.
Don’t deviate your attention to guesses and personal opinion. Simply present the facts. Be objective.
Bug Issue Severity
Testers are the first point of contact with an issue and raise it to the level of the understanding of how severe is the bug. The level of severity can vary from team to team, most specifically from developer and management you are involved with. Don’t classify the bug based on personal view or opinion, take it from what is the level of severity in terms of blockage, security, and functionality.
Bug Issue Opinion
You as quality assurance representant of the team, have to avoid at all costs you personal opinion.
There are moments this is simply not possible. You just have to gather as much as evidence and information based in facts to
defend your point. All parts will be willing to listen to your viewpoint but if you don’t offer something substantial, no one
will listen to you.
Raise Bug Issue When is Not An Actual Bug
Don’t fall into the trap of reporting something that doesn’t actually exists. If you find
something that you may believe is an issue and even unique, do make sure you have it retested and covered all the basis before reporting.
Ex: Simply forget to clear your browser cache can lead to a false positive and in some cases an error is placed in the code intentional.
Talk to the team and investigate before raising something that falls into that subject.
Raise a Bug Issue With No Information
When it get to the time to raise an issue, make sure you gather all the necessary information.
Based on the expected results, provide the steps to reproduce the error plus the data used so developers can debug and fix the bug.
With that in mind, both you and who is going to fix the issue be able to reproduce the bug.
Bug Issue Raised In Error
Pay attention to raising an issue when a test is carried out wrong with wrong information or wrong set of data not
following a structure previously planned. Pay attention to following the test plan and test cases and always double check the environment availability, suitable data, and business cases.
Wrong Bug Issue Information Raised
Sometimes a bug can be a super bug. Consider the bigger picture before raising an issue as it can be just the tip of the iceberg. Do your own diligence and investigate all the angles, investigating, testing, double checking before reporting something.
Bug Issue Raised Disrespectful
As well as based on personal opinion, watch out for how you express yourself pointing out the facts.
Don’t write something in which will potentially irritate other stakeholders, this will only make matters worse denigrating the developers work and make your presence unlikeable.
Bug Issue With Insufficient Information
There are some bug issues raised out there with very little information, some of them with just a title or no relevant information at all. Elaborate well the bug raised, is your job to do so and not the developer to guess “a not working” issue.
Bug Issue With non-Relevant Information
Don’t write a bug for the sake of writing something to fill in the gaps or something that is not relevant to the bug.
Focus on the expected results and how it’s behaving giving facts and data used so developers can reproduce, debug and fix the issue.
Don’t assume devs will know what you are talking about just because you have added a bulk load of information to the bug report.
Duplicated Bug Issue Raised
Never, Ever and Ever duplicate a bug. This is not professional and shows that you are not engaging with the team and aware of what is going on with the release/feature/development/change request/improvement with the software cycle you are working on.
Always check within the bug report tool you are using for the same bug already raised by you or another member of the team.