A list of questions to ask, by Michal Bolton, prompted me to write about assumptions. Most of these ideas come from doing the ‘dropping a calculator’ exercise with James Bach.
Why do we need to make assumptions ?
Asking questions is very good, but in some cases we can not get the answers. There could be different reasons :
- There is no-one to ask from – assignment arrived in mail.
- The client does not know the answers.
- The client is busy and will answer in few days (hopefully)
- Etc.
Now, as we all know, making reckless assumptions is bad, but in order to not to waste valuable time, we should start testing right away. But how to avoid the problems with false assumptions? After all, even if we do get answers, some of those are ambiguous, some false, and some questions we forget to ask. Thus we cannot escape making assumptions.
What to do with the assumptions ?
As MB said in the comments: “… sometimes stating an assumption is a very useful proxy for asking a question.”
We should write them down in any way that counts, to make them visible to those who might correct us :
- E-mail them to your client
- Put them up in internal wiki/forum
- Put them into the Test Plan
- Etc.
But how does that help ?
There are several very good reasons for publishing your assumptions :
- People are not mind-readers, they cannot correct you if they do not know what you assume.
- People can (and usually will) correct you sooner
- Protecting one from accusation of testing the unneccessary areas
- Protecting one from accusation of not testing the critical areas
- Etc
Which assumptions to ‘state’ ?
Surely, all of them would be the best approach. Alas, that might not be practical for all sort of reasons. Impossibility being one of them. Therefore we need to make a choice and for that we need to analyze the assumptions. All of them share these aspects:
- Probability – how likely the assumption is to be true (or false)
- Impact – what would happen if the assumption would turn out to be false
- Context – You are making the assumption in a certain context, depending on your knowledge and experience. What if someone important would make a different assumption?
By assessing these aspect one can make an educated choice.
So, are we now done with them ?
No! They need to be revisited – importance assessed, corrected if necessary, communicated again, etc. They are valuable tools for provoking answers, but only if used wisely.
Notes to Self 
Hi,
Yes, assumptions are powerful things! The trick is to try and use them (and handle them) at the right time and in the right place – you mentioned some examples about unavailability of an oracle or expert.
But, of course, assumptions are all around us – the trick for a tester is to be aware of them, state or document or remember them, and confirm or dismiss as needed.
Assumptions are also made by people we work with – whether colleagues, project stakeholders or customers. Sometimes these might have a bearing on the testing work, might be stated, might not even be known about by the person using it (an inherited assumption). Some of the context-free and context-related questions will help to highlight some of the assumptions – sometimes. I highlighted some assumptions I’d seen in others, here, but there are plenty more.
The key is to understand the assumptions we have/encounter as best we can, and direct our work/questions accordingly.
I agree, i think i missed mentioning specifically that one should always communicate their assumptions.
And thank you for the list, I intentionally did not produce examples of assumptions. The post would have gone too long otherwise.
Nice post, it’s always good to see people highlighting awareness of assumptions. To me assumptions can be a powerful means for communication & debate when scoping a project. They can also be traps when testing new functionality, more often than not assumptions are dangerous. Hence why it always pays to always question your assumptions.
As I was reading this post I rapidly realised, that assumptions is one of those points where analysis and testing meet.
The situation in alaysis is actually quite the same. While analysing some sort of requirements – which usually are not exposed until the analysis is actually done, and as you know, come in belletristic kind of style – one makes assumtions. A lot of them. And, being frank, it is the only thing one does in the first stages of busyness or system analysis. The result may be structured, well formulated and even clear, but first it is only assuption.
Analysing resulting assumptions with client, another analyst (and later with senior developer, senior tester) – that’s where the fun part begins.
Hello,
To some extend a tester needs to make some assumptions but she needs to be aware of them. Science, discoveries or medicines are created based on assumptions.
Writing down or being aware of assumption is a great deal. A tester needs to practice challenging assumption by asking questions.
Very informative article.
Soon i will be publishing same topic on my blog.