It was my best friend’s wedding. Since the wedding ceremony was planned to be a grand occasion, I decided to help him with the wedding arrangements. I contacted the best oragnisers and kept track of most of the activities.
Finally most awaited moment had arrived. It was time to wear the wedding ring. My friend asked me “Get the wedding ring? I asked “What?, I do not have the wedding ring”. To which he replied, “You were supposed to get the ring from the jeweler”. I said “I thought you were supposed to get the ring?”.
I realized we were in real trouble. We both made assumption.
The experience is not very different in software development.
Let us first understand the meaning of assumption
Oxford dictionary defines assumption as a belief or feeling that something is true or that something will happen, although there is no proof.
Let us start with requirement phase. While documenting requirements the Business Analysts may make assumptions. Some of them can be,
1.Information about few conditions and/ or associated behavior is missing, hence perceptions are given more importance than facts.
2.System behavior interpreted differently because it has more than one meaning.
3.System behavior complex and so a simplified understanding is considered.
These assumptions become input for designers/architects, developers and they implement without questioning them or asking for evidences. Ultimately leading to buggy software.
The story is not different for software designers/architects. Designers too add their assumptions when designing the solutions. Some of them can be,
1.Requirement X will certainly not change, hence we may not factor changes in the design
2.The data source will be XML file, as previous projects used XML.
The developers also continue to take the same path as others did. They make assumptions on,
1.Input parameters for a function
2.Return type of a function
So what should you do? Record assumptions and test them. That’s when you are really doing software testing.