Would Heu-risk it? Part 17: Fools´ Assumptions
This trap is not something that only testers fall into, I´d say we are better than most at avoiding it. It is still very hard to avoid and makes a lot of difference when we do! The rhyme is one of my favourites:
”Friendly questions save the day
Make foolish assumptions go away
Who knows if they meant what it means for you
Keep asking: why, what and of course: who?”
So, what does it mean?
The first card I wrote about was Mischievous Misconceptions and someone might think, ”Isn’t this just the same thing?
Well, not exactly. Collins Key has a TedX talk about ”The Surprising Secret of Solving Problems Quickly” where he talks about misconceptions, assumptions and expectations.
Misconceptions are things we believe because of how we are used to seeing it presented. (”all days have 24 hours”, ”bulls hate red”)
Assumptions are things we believe without having any proof, or even a real reason. Definition from my dictionary ”a thing that is accepted as true or as certain to happen, without proof”.
This card, to me, is about all of the things we read into what people write/say/do, because of our own experience, taste and context.
Say you are reading a traditional requirement specification (or if that hurts too much: imagine a user story or a conversation). So much information is crammed into it, but no matter how good it is or how long it is – there will still be information missing. And I promise you, no matter how much you think otherwise – you are making assumptions without even thinking about them.
This is nothing new, most of us know about it. There is a well known (un intended) quote by Rumsfeldt about known knowns, known unknowns and unknown and this picture of a swing is used a lot in testing and requirement courses I’ve ever taken over the years
Or, one might illustrate it as an ice berg. With all the things that have been explicitly said over the surface and all of the unspoken expectations, wishes and information below.
We need to do this. We have to make assumptions all the time, otherwise we could never make any progress on anything.
What we should do though, is to make those assumptions explicit.
It can be incredibly tough to start, because it can often feel like such a stupid thing to do. (”Of course that is what the author meant, why are we even wasting time spelling it out?”) It can also be very difficult to identify the assumptions we make unconsciously.
But the good part is: It gets easier with time! And after few tries people will hopefully realize that the obvious answer was not so obvious.
In our speed-testing workshop, Tomas Rosenquist and I have this as a separate task for the participants. They get a spec, they write a rough plan of how to test it and then we ask them to write down all the assumptions they have to make. In the discussions afterwards it is incredibly interesting to hear people realize how differently people interpret things and how things can seem so 100% obvious to someone, even if it’s not even mentioned in the text.
A very good exercise indeed!
By making your assumptions explicit you get a lot of benefits, such as:
– You make yourself aware, increasing probability that you will actually question yourself
– You can ask people to verify or falsify them, making sure you don’t waste time on incorrect testing.
– Someone else might realize they had made assumptions that are incorrect, making sure they don’t waste their time
– The author might realize they had not thought about a certain aspect, making sure you don’t build the wrong product.
Story time
The most interesting story I could think of is an application I worked on way back. I worked in the team working on the general product and then we had a bunch of teams working on different customer adaptations to that core product. We had a very large customer implementation project inching closer and closer to release but at one point in time we got a bug from them that was a true show-stopper to them.
After a lot of debugging and investigation we realized that their work process went against the architecture of the application and that the problem was actually in the limitations of the browser that the customer wanted to use.
We had at some point in time assumed a certain process and build the system for that.
The sales team had sold a product, making assumptions that we could adapt the system.
The client had their process and assumed that they could keep working in that way.
We offered a number of different solutions but the only solution accepted would have been to change the limitations to the browser or re-write the entire architecture of the application.
I don’t know if there was even a way we could have figured this out and solved it, but getting that bug in acceptance test meant that the entire project was in risk. I am not 100% sure but I think they never got past that issue.
So, that turned out to be an extremely important requirement that people just assumed would work out of the box. If I remember correctly it was never written down as a requirement.
Customer assumed we understood how they wanted to work and that we could just… I don’t know… call <unnamed browser company>?
Sales assumed this wasn’t a problem and didn’t consult any tech people.
Customer implementation team assumed we would fix it.
We assumed sales and customers would understand technical limitations.
Quote of the day
”When you ASSUME, you make an ASS of U and ME”
Unknown origin. Definitely earlier than “Odd couple”. Can be found in the 1966 issue of PMI, Photo Methods for Industry
Reading suggestions
Interesting thread about misconceptions, assumptions etc – Stack Exchange
Kano model – Kano model
Kano model – Wikipedia
Making implicit assumptions explicit – Enterprise craftmanship
Making assumptions explicit – Walker, Charles A.
It’s not all requirements – assumptions and restraints matter too – Laura Brandenburg
How to create a project assumption list – Leigh Espy
Previous posts in the series
| Title and link | Category |
| Part 1: Introduction | None |
| Part 2: Mischievous Misconceptions | Trap |
| Part 3: The Rift | Weapon |
| Part 4: The Fascade | Tool |
| Part 5: The Temptress’ Trails | Trap |
| Part 6: Allies | Weapon |
| Part 7: Don’t turn back | Tool |
| Part 8: The Glutton | Trap |
| Part 9: Beyond the border | Weapon |
| Part 10: Forever and never | Tool |
| Part 11: The Shallows | Trap |
| Part 12: The Twins | Weapon |
| Part 13: The Observer | Tool |
| Part 14: Alethephobia | Trap |
| Part 15: Opus interruptus | Weapon |
| Part 16: The Illusionist | Tool |
Om författaren
