3 Strategies for Dealing with a Blocker Defect

Blocker defects add tons of drama to otherwise regular test days.

In this article, I want to cover some steps a tester can take when dealing with them.

I am going to assume that our dear readers already understand Severity and Priority of defects deeply. Need a quick recap? Check this out.

Now, does it always mean we need to completely stop testing if we come across a blocker issue? 

In some cases “Yes”, but maybe not always. There could be instances where some testing activity is possible.

image source

Below are some situations that I have experienced in my career as a tester. I strongly believe that the steps outlined below (later consolidated into a flowchart) are to be followed to make this process simpler.

Let’s jump right in.

Steps you should take when you come across a blocker defect

Step #1: When you come across an issue, invest time to find the root cause.

I strongly believe that as a tester our work just doesn’t end at reporting defects. If time permits, we should explore what could have caused the issue. We may not always be able to point out the exact problem area, but try to troubleshoot as much as possible. The same details can be updated in the defect as additional comments.

I have done this a lot in my projects, and this has resulted in a quick fix. The benefits of root cause analysis are:

So, I suggest we always double check at our end before logging a defect.

Here are some real-time examples from my projects that will reinforce the above points:

I worked on a project where our testing would require us to drop a file at a specified location. Rename it to match to the name in the configuration. A scheduled job would pick up the data file and load the data into the system. After which, we would validate the data in the database and the front end.

We used to come across issues where the job would run but the data wouldn’t load, and upon investigation, it was because the tester has not changed the name while dropping the file at the location.

This was a blocker for us but not something that required developer attention. We had to pay attention to detail and avoid such small mistakes.

The following are some common categories, root causes, and remedies:

#1) Hosts File Issue– Say, your hosts file has parameters that are incorrect and are causing the problem. In this case, you can either update the host file yourself or seek help from someone with access to update and continue test execution.

A defect for the same should be raised so developers will investigate but with the workaround functional testing can still be continued.

Note: Check with your project teams if it is OK for QA team to make these changes before doing so.

#2) Configuration– Often, we have noted configuration issues such as not pointing to the correct environment or other set up problems, which are blocking issues. In such cases too, testers can make changes and proceed with testing.

Note: Once again, seek permission before doing this.

#3) Code Issue – If you feel that the issue is due to code, nothing much can be done by the testers. Log a blocker defect and wait for the fix to proceed with testing.

#4) Deployment Issue – Bad deployment is another common cause for blocker issues and these can be caught during the sanity test. Here too, testing should be stopped immediately until a new build is received.

#5) Environment Down – If the environment is down, say the Database is not getting connected to the server or the URL is not working in case of websites; testers cannot do much in these cases other than report a defect and wait for the system to be up and running.

Therefore, if a workaround exists, use it in order to continue testing. The only way to find, if that said workaround exists, is by investigating the root cause. More often than not, there might be an alternative.

Step #2: It is very easy to fall into an infinite loop when investigating the root cause. So, make sure it is not consuming all day and all effort.

Here are some pointers:

Reason why blocker defects should be reported immediately:

Step #3: Now, moving onto the last step since we are done analyzing the issue and communicating it, what’s next?

Finally, the flowchart that summarizes the entire discussion!

Flowchart: Steps to handle a blocker defect

Author: This awesome article is written by STH team member Priya R.

What steps do you take when you come across any blocker defect?