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? 
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ā.
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 
Testing is indeed much more than just checking the requirements against the SUT.