Bugs, errors and issues! These are what the life of an SQA engineer normally revolves around. You write test cases, execute them, identify bugs and report them constantly. Just because you reported three pages worth of issues doesn't mean all of them will be handled and solved by the developers. Some could be ignored, postponed or even re-named as a new "feature", like the undo feature in Gmail.
This article will highlight a few things that might help you get your bugs fixed.
Choose Your Battlefield Wisely
Fighting for every bug you encounter could do more harm than good. It may look like you're trying to get attention, but the attention for the higher-priority bugs might get lost in the process.
Viewing from a real-world perspective, not every bug will be fixed. You will inevitably come across your development team saying something like "This can't be fixed now. Will do later" or "Will look into it later. postponed for now." for the bugs you found on the application.
So categorizing your bugs on their severity and priority will make it easier to fight for the ones that need fixing immediately. Following are some ways you can base your categories on.
1. User Impact of the Bug
You must consider how big of an impact your bug can cause on the user experience. Suppose users cannot send invitations to their friends when clicking the 'Invite' button. This will have a bigger impact on the user than when a confirmation message of the copied Room Code is not displayed or when the position of players in the game is asymmetric.
2. Likelihood of Encounter
While choosing your battlefield, it is important to consider how often the user encounters the bug. If a bug arises through a sequence of calculated steps from a tester's mind, it will be less likely to be encountered by a normal user.
As a tester, you need to think of out-of-the-box scenarios to ensure the quality of any application. You may look for various loopholes that could be in the application. For instance, you create a room, invite friends to a multiplayer game, and then turn off the Wi-Fi. Maybe you could start the game and turn the Wi-Fi off, or you could minimize the app multiple times simultaneously to test how the application would perform under such situations.
A normal user would not do so willingly while using the application. However, bugs such as a button not working or players not being able to equip their bought items are very likely to be encountered by a user.
Thus, you must keep these two factors in mind while preparing for your battle. This will help you take a higher stand and advocate for why your bugs must be fixed.
Bug in Action
You may be wondering, "I just noted all the issues in a detailed way. Why do I need to show it again?" A valid thought, but for practical reasons, don't you think it would be better to have some solid proof to back up your issues?
Let me elaborate using an example of our car parking game. You must park the car by reversing it at a certain level. However, a loophole allows the user to park the car without reversing it due to a larger space or the absence of an obstacle. Your developer might dismiss this issue, thinking it's not a big deal. So, providing a recording of the issue in action will help you show how that issue deliberately contradicts the objective of the level, i.e. reverse car parking.
Screenshots, screen recordings, or personal displays of the bugs will help you get your development team's attention. You will also have a recording of the bug that the developer can not dismiss without looking into it at least once.
Prioritize Customer Feedback
A business should always put their customer on top. They should cater for their needs and desires over everything. A product that is not loved by customers will bring no benefit to the business, irrespective of how good you think your product is. This is why feedback from your customer is crucial and significant in retaining them.
For instance, if your customers are fed up with dying in the 99th level on every Snake and Ladders game, you have to get your developers' attention towards it. The developer may think it adds thrill when the user gets eaten by a snake so close to victory. However, if users die on the 99th spot in every game, it would be too frustrating for them to continue playing the game.
Considering this scenario, developers may say that it was the requirement or it is what they made. However, as an SQA engineer, you need to take feedback seriously. If most users complain about something, the defect is definitely in the product, not their opinion. Moreover, it helps to move the app towards a path that makes it more approachable and enjoyable to the users. This also contributes to making the development team more aware of usability testing by showing them the user's perspective on a product.
Walk a Mile in the User's Shoes
This may look similar to the above point. However, I felt it deserved its own separate place. We all know UI and UX play a major role in taking the spot of a user's favourite app. While describing any bugs, express the steps from the perspective of the end users. It is crucial not to make the users feel lost or confused at any step.
For instance, if a blank page is displayed instead of a loading indicator, it would cause some sort of confusion for the user. In another situation, if a process takes too long, it will make the user feel lost as to why the transaction did not occur. They can spam a button, thinking no process is being done, which can lead the app to crash or freeze, which is something to avoid from happening. Expressing these issues from the user's point of view is crucial to indicate the issue's significance in the app.
It's a Wrap!
Time is very crucial during the venture of any software development. It is very important to emphasize the bugs that need the attention of your development team without wasting their time and effort. With these few points to remember, you can always obligate developers to fix the bugs you pushed.
Thank you for reading. Please subscribe to our DevBlog for more!