Requirements and Presumptions

A common theme at conferences and workshops is "tell a story" - so here we go.

Once upon a time, there was a software project. This project had a variety of components, some were better understood than others. As sometimes happens, information was presented decisions were made in discussions where not all the interested parties are present. In this case, the testers were wrapping up another project and others involved in this one made the decision that testers weren't really "needed" yet.

So, life went on. The testers finished their project. They were given copies of the documents that had been prepared on this project. So they read the documents and worked on their own documents, like test plans and test cases. More meetings happened and conversations happened and emails were sent and read and replied to (well, were certainly replied to, maybe they were read by everyone.) Some of these had everyone present or copied or included, and some did not.

When the intrepid testing folks compared notes on an item described in the requirements documentation, they realized their understanding on did not match. No problem! They asked the tech lead to clarify what the correct interpretation should be. The answer? Neither was correct. And he explained why.

He then decided to verify what he had reported and brought the question to the business experts. Their answer consisted of "Well, everyone knows what that means..." and then they realized they each "business expert" had a different understanding of this very, basic element of their requirements.

No one had thought to define the terms. Then, to make it worse, no one had asked what the terms meant. It is possible that each participant believed they shared a common understanding. However, no one made sure that was the case.

I was not part of this project. It strikes me that most people fall into this trap at least once. Sometimes, twice.

Always question your unquestionable facts. They may not be as factual as you presume.