Strategies For Dealing With A Blocker Defect

Blocker! What a blocker defect is? In Software Testing, we come across various kinds of Defects. What is the extent of that defect and what should be the order to resolving that defect is the severity and priority of that defect?

Now the question is how to decide the severity and priority of a bug or defect?

The Severity and Priority of a bug are decided by the business provider and the bug triage meeting members.

Last Monday, I was working on a mobile application and come across a defect in which I was not able to Log in. That was almost a headache for our team as the build is delivered to the QA team and such kind of defect can affect the deliverables of the product as we were not able to test the further functionality.

We immediately reported that bug as a blocker and inform our team members about that bug that it might affect the deliverables.

So, a defect that can cause the failure of functionality and due to which user is unable to test the near around or the remaining functionality comes under the blocker defect.

Concerning the severity and priority of a blocker, a blocker issue should be a file with high severity and high priority. It depends on which bug reporting tool you are using, some testers also customize the severity as a blocker or show stopper and priority as immediate.

Blocker issues should be raised immediately and a team scrum or email regarding the deliverables should be sent to the Team members, if necessary.

ad-blocker

While filing a bug as a blocker a tester should be attentive and careful as sometimes it may affect the relationship of a tester and the dev. team.

Now to prevent the relationship and to deliver the best quality of a product we should analyse the situation while reporting a bug as a blocker:

1. A tester should check the Network connection whether the Wi-Fi network or Sim Card network is available or not. It may be a case of network failure and the absence of a Validation message.
2. Check for the configuration for the hardware and operation system or for browser versions, it may be an issue of forwarding or backward compatibility.
3. Check whether it is a failure of the environment which you have set for the testing.
4. Check whether it is an issue of the wrong deployment of the build.
5. Check whether it is a regressive issue then it will be easier for the development team to fix the issue faster.
6. Check whether the Database and Hosting server are working fine or not.

If we are expecting a bug as a blocker then we have to analyze the root cause of the bug. We have to also keep in mind the timeline and deliverables of the product and try to conquer the situation which a blocker has created.

If execution of the code is not possible then we can go for the static testing. If there is a problem with the front end then we can go with the back end i.e. Database Testing, Web services or API testing services.

Try to test the other modules if possible in case of a blocker issue. So to overcome a Blocker defect we should work more as a team than as an individual and always try to find the root cause of the problem.

Munish Garg

Munish Garg, is a Senior Coordinator QA Engineer & Editor associated with BugRaptors. He’s extremely passionate about his profession. His forte in testing is API testing using tools like Rest Assured, Postman etc. He’s a great team player and loves to help everyone. In addition to testing, he’s also fond of writing code which he likes to implement in his domain. He also loves to read and travel to new places.