Blocker Defect in Testing, Example and Steps to Handle It

In this article, we have provided our readers with the best 3 strategies for dealing with a blocker defect. We will cover some key steps a tester can take when dealing with them. Let’s get started. 

Blocker defects add a lot of drama to what would otherwise be just regular test days.

I’m going to assume that our readers already understand the concept of Severity and Priority of defects. Do you 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.

3 Strategies for Dealing with a Blocker Defect:

Given below are a few 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 begin.

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. We can update the same details 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 as follows:

• Being a value-add, this can definitely provide a better direction to the developer for bug fixing.
• Also, the QA tester can recognize if this issue is self-created (data entry or human usage problems) and if so, can be fixed by the tester itself. When such errors get reported to developers without us checking from the QA end, they are considered a non-issue and could create a negative reputation for the tester.

I suggest we always double check on our end before logging the 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 the name in the configuration. The scheduled job would pick up the data file and load the data into the system. After which, we will 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 had 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 a few common categories, root causes, and remedies:

#1) Hosts File Issue– Say, your host 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 can 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 deployments are another common cause for blocker issues and these can be caught during the sanity test. Here too, testing should stop 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 out if the 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 a few pointers:

• Find a balance and recognize the stopping point when you get there.
• The tester’s experience and expertise are critical for a successful RCA. However, it is a good idea to involve the team and team lead when necessary.
• If you feel that RCA is time-consuming, first report the issue immediately and provide as much information as you can. A screenshot would always be helpful.
• Follow up if required. Send an email to the manager or developer to bring attention to the critical problem.
• Continue troubleshooting after alerting the necessary parties.

Here are a few reasons why blocker defects should be reported immediately:

• Management should be made aware of all downtimes if the issue happens to be a showstopper defect. This information has to be relayed to the client and may also call for project plan updates (QA timelines), changes in deliverables, etc.
• Any delay in QA deliverables has to be supported with evidence. So it is always better to communicate as soon as possible instead of waiting till the end of the day.

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

• If the issue is blocking access to one functional area, check if this has an impact on other areas
• If the front end app is down, check if backend/middleware/database testing can continue.
• If no test execution activity can take place, try to work on some documentation related to your project.
• You can also try to identify areas for automation if you are manually repeating a lot of work. Automation doesn’t always have to be using a tool. Say, report generation is a monotonous task for you, that is one area that can be automated by simple excel macros and such.
• Spend time learning about open source tools that can be implemented in your project
• Last but not least, work towards innovation, the mantra that’s currently ruling the world!

Finally, a flowchart that summarizes the entire discussion!

Flowchart: Steps to handle a blocker defect

Let us know what steps you have taken if you come across any blocker defects. Feel free to post your feedback/queries in the comments section. We would love to hear from you.