After Ben Fellows brilliant Risk Storming workshop at the #MidsTest meetup, I decided to purchase myself a set of Test Sphere cards. A round of Test Sphere solitaire has yielded some interesting ideas and stories.
I was very interested in the Ministry of Testings Test Sphere challenge which encouraged participants to pick a card and tell a story. Some of these stories have been shared on The Club – I might start sharing some stories on there as well.
The card I picked at random was the Ostrich Effect Pattern card.
The Ostrich Effect
I’d never heard of the Ostrich Effect before I saw this card so had to do a little googling first. The term is related to the idea that some might decide to ignore instead of actually dealing with it. They ‘bury their head in the sand’ and hopes the problem goes away. Most examples found online relate to financial issues, like large bills appearing a week before pay day.
I definitely have some stories to tell about testing and the ostrich effect.
I’ve never been afraid to report issues. As a software tester, I want the quality of an application to be as high as possible. A bug lowers the quality of the application, so it is my duty to report it. It is not up to me if the bug gets fixed or not. That decision is made by the business. I help the business make that decision by providing as much information about the defect as possible. This includes details about the severity and impact to the business and user.
There was one occasion where we were due to release within a couple of hours. I was doing some last minute exploratory testing of the application to make sure everything was fine for release. It was at this point that I spotted a bug, a critical one. It was one of those that could only affect 1 or 2 users (if any), but the consequences could have been severe. I didn’t even write up the bug report, I went straight to management and broke the news to them – I was recommending that they pull the plug on release.
This isn’t an example of the ostrich effect but it could have been. We had been told that nothing could prevent this release. Fortunately the unspoken phrase, ‘unless there is a critical bug’ was included in that edict. Despite this pressure, it was decided to push back the release by a couple of days while we fixed the bug, and retested the application. We completed the release 2 days late, but had removed this particular bug.
There are many ways in which this story could have gone differently. The tester might have decided to keep quiet and let the release go ahead. The business may have decided to ignore the tester and release anyway. What could cause these decisions to have been made?
How can ‘feelings’ effect testing?
The Test Sphere pack include several categories of cards, including ‘feelings’. Feelings can really effect the way testing is carried out, and are likely to increase the chances of an Ostrich Effect. I decided to go through the ‘feelings’ cards to identify potential causes.
If the tester doubts themselves or is new to the team, they may be hesitant about reporting a bug. It only affects a small number of users. Should we really be bothering the business with this defect?
The team have been working on this application for some time and are really anxious to get it released. We don’t care about the quality any more, we just want to get it out of the door.
The whole release could be held up because of this bug. Could it have been found sooner? The team might blame the tester for this.
The application has been thoroughly tested, everything is good and we’re happy to release the application. Why find a way to ruin everything?
Further Reading – Test Sphere
- Discussion about how other teams are using test sphere
- More Test Sphere stories about the Ostrich Effect
- Introduction to the Test Sphere challenge
- Link to purchase Test Sphere cards
- TestSphere on Twitter