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.
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:
- Being a value-add, this can definitely provide 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.
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:
- Find a balance and recognize the stopping point when you get there.
- A 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.
- When you feel that RCA is time-consuming, first report the issue immediately and provide as much information as you can. A screenshot is always helpful.
- If required, follow up. Send an email to the manager or developer to bring attention to the critical problem.
- Continue troubleshooting after alerting the necessary parties.
Reason 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), change 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 be continued.
- 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 knowing about open source tools that can be implemented in your project
- Last but not the least, work towards innovation, the mantra that’s ruling the world currently!
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?
10 thoughts on “3 Strategies for Dealing with a Blocker Defect”
very good steps for dealing with blocker defects.
Very good Analysis and Nice article about the issues faced by Testing community.
Frankly speaking, nothing new in this article. This is what normally followed, that tester give their feedback on issue to get quick resolve or look for alternate way to proceed in execution to meet the daily/weekly target.
Coming innovation, it doesn’t need to wait till a blocker is encountered quickly achieve the daily target and people can involve in other interest unless Testing is lagging behind heavily.
I am not satisfied with this article.
A step by step guide not only to proceeding towards issue resolution process but also to avoid unnecessary wasting of testers time at the end of the day.Realy well written and explained as real time testing does not end up in smooth process,facing above mentioned problems leads to waste of time and efforts.kip posting.
Really very good steps to handle blocker issues.
@All – Thanks for valuable comments!
I agree nothing new has been captured in this article,its mostly what we all testers do in our day to day activity.These type of articles are meant to help and give an insight to people who are new to the field of software testing.
I hope this helps the freshers.
Thanks for sharing your thoughts.
Good write up for a tester. The last diamond in flow chart can say non execution activities as non functional testing by itself has a diff meaning and a phase all together.
Thanks fro the valuable post..
Very Nicely written.