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 resolve that defect is 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 is decided by 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 which can cause failure of a functionality and due to which user is unable to test the near around or the remaining functionality, comes under the blocker defect.

Concerning about the severity and priority of a blocker, a blocker issue should be file with high severity and high priority. It depends on which bug reporting tool you are using, some testers also customize the severity as 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.

While filing a bug as blocker a tester should be attentive and careful as sometime 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 analyses the situation while reporting a bug as 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 Validation message.
• 2. Check for the configuration for the hardware and operation system or for browser versions, it may be an issue of forward 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 wrong deployment of build.
• 5. Check whether it is 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 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 problem with front end then we can go with back end i.e. Database Testing, Web services or API Testing.

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.

The post Strategies for Dealing with a Blocker Defect appeared first on BugRaptors.