Should we make any assumptions?

As testers we are often confronted with few or even no requirements at all. Shouldn’t we be wondering what the developer is going to build in such a situation? :thinking:

But more important, what is your strategy and how do you proceed in this situation?

For context, I am the founder of the ‘early Model Based Testing’ (eMBT) approach and the supported eMBT tool TestCompass and I’m keen to learn from you all.


Never Assume, it will make an ASS out of U and ME.
I keep asking for requirements or nothing will be tested nor will I give a GO.



Totally agree…

If we want to compare the required status and the actual status of the test object (= checking), we need a reference (=requirements). We cannot do the checking part without requirements. Just like we can’t this do without the SUT.


Indeed and this does not only count for functional requirements but also non-functional.

Such as for performance testing, whenever I meet a client they have no requirements at all. ‘It has to be fast’
So often we test their performance based on what type of test they need but we do NOT say it’s fast nor slow. We just say ‘these are the results and without requirements we cannot define them’.


This post was flagged by the community and is temporarily hidden.

He he. it’s a bit of a loaded question. As someone who has not been a tester that long, but have been a coder for long enough I have already a firm opinion on how assumptions around a product work.

And no I’m not talking about the tired old “build me a swing” meme - I mean this picture was a meme long before memes even existed.
…so I’m going to suggest testers look at the “entire product” more often than at just one piece, because models, integrations, environments, black, white and boundary analysis, performance, and expectations etc. all are tools in a box that inform us of the quality of a product. This last few weeks I have had a few assumptions of my own shattered. Due entirely to release pressures the testing squad have pushed back on testing work around new features and prioritized the testing of bugfixes and any committed to deadlines. A side effect of that was that devs have to do more of their own testing than usual. And this tweet by someone I have a crush on although I’m sure she is unaware of it, was my regular reminder.

The job of every tester is to spot assumptions in the wild, collect and corral them and then design useful experiments that prove or disprove the valuable ones. What tool we decide to use for that is always going to be context specific and rely on experience. Always assume that you can learn a new thing every day.


That’s exactly why I’ve wrote about checking in my post :wink:
Testing is indeed much more than just checking the requirements against the SUT.

1 Like