Tunnel vision during testing

Have you ever experienced tunnel vision when testing? I’ve done this in the past and gone down a thought process and forgotten to check certain things.

How do you stop testing tunnel vision?


Yes, I absolutely have experienced this…so much so that it is hard for me to not focus fully on security issues when I am testing. I have dealved so deeply into this realm of quality and testing, so my mind has become super focussed on it. It means I sometimes easily miss other aspects of quality. It was at its worst when my mental health was bad also. I think it’s worth exploring further if you would like to have a proper chat about it sometime.


I’d love that @danielbilling ! We could brainstorm some thoughts about it. I’ll reach out to organise a chat. If anyone else wants to join, shout!


Test analysis and planning is an engineering activity like any other, so of course it needs…a cycle!

Capture => Review => Update

Basically, I gather information, record what. I know so far. I review with others, I update my gathered information… Repeat.

Works well when building diagrams and models of the SUT…

TL;DR remember to review your coverage with others to get fresh ideas.


My course “Cognitive Biases in Testing, A Beginners Guide” deals with this topic!
It goes live this week :slight_smile:


patiently waits for this to go live @maaike.brinkhof


Shameless Plug but I’ll allow it @maaike.brinkhof :rofl:


Sorry, my SEO algorithm got triggered :smirk:


I found this post quite useful in describing the causes of tunnel vision and what you can do to stop it https://link.medium.com/T5nxPp94seb


that’s probably what I drew as a cartoon here:


So much more difficult if you don’t have a review process and don’t have space to step away from the issue/tree/coal-face/problem. The tunnel vision problem happens to us all, some of our best war stories come out of it, but we forget some of our best victories.

In my career, coalface is very relevant, we did a lot of work for mines. Once I had to interface to equipment that could only be used underground, (or fly to Austria to the makers) I was given 1 hour max, instead all I did was hook up a sniffer, which I left running for a 5 minutes while I explored the dark of the tunnel and ran a small test app, and was finished in a few minutes. I could have stressed to make every minute count coding the solution while I had direct access to the system, instead I chose to use the rest of my hour to trudge through the black mud to where everyone else was working, just to observe the machine that cut coal out of the ground and fed it onto a conveyor. Never rush, I learned that lesson on a prior visit to another mine where my CTO promptly announced at 7pm after a whole day debugging that, it’s dinner time. We were so close, but no. We went back to the canteen, and the next morning had it reviewed and tested the change properly in a few minutes with that good night’s rest behind us. It’s never worth trying to get it complete without making sure that you have more than one chance, to step back and check your work from a distance before you sign off on the day.

1 Like

:slight_smile: what an awesome cartoon!!! Depicts it perfectly.

For testing I use test charters. Most of the time the purpose and the time limit of the test charter keeps me focused.

I allow myself the following exceptions:

  • critical bugs (security and legal stuff)
  • fast progress which allows more exploration outside the scope.
1 Like

As testers it is normal to be focused on a specific task and sometimes overlook easy bugs. I mean you have been on that system 1000+ times and for you all looks ok.

To try and make the tunnel as short as possible I do 2 things:

  • Make a list, a plan of what I am about to test
  • Double check that list with someone else from the team
  • Start testing

In an ideal case the first 2 points would happen in the requirements phase and I would just add to the list/lists as the application grows.

I hope it helps

1 Like