The silent conference room was suffocating and everyone inside it was confused. How could we miss it, was the question everyone’s face reflected.
After all, not showing up with any relevant error when the user tries to duplicate the existing record and allowing him to do so was not a small bug- That too for an insurance company.
After deciding to nail down the issue, everyone dispersed. And while digging out, it was observed that client never mentioned anything about duplicity of records in the requirements document and therefore no one asked relevant questions or thought about it.
This was just an example.
In a career of more than 10 years, I have observed many numbers of cases where projects suffered due to bad or poor requirements.
But as they say, nothing is perfect in this world and you will have to deal with it and dealing with projects having no requirements or poor requirements is a nightmare of sorts.
Let me explain –
#1) No requirements – No requirements implies assumptions & guesses and therefore there is no confidence. It is very difficult to test a product/application without any baseline. And these results in more work, more bugs from client and more suffering for the project.
More information on No requirements and how to handle the situation while testing can be found in earlier published article – How to Test an Application without Requirements?
#2) Poor requirements – The quote, Knowing something incomplete is dangerous than not knowing it at all, is very true when it comes to dealing with a poor requirement.
Interpreting a poor requirement and implementing the same is a big risk.
#3) Conflicting Requirements – Asking someone to do two different things at same time is just getting him/her confused and system too is not an exception.
And that is how, the bad, poor and conflicting requirements create hassles.
Being in software industry, it should be part of project as sometimes even customer is not sure what exactly they want and how to word it.
From testing perspective, although it’s difficult to handle those ambiguous or vague requirements, it’s not completely impossible.
Let’s look at the possible solutions:
Method #1) Explore and Learn:
Exploring other applications, learning about general expected behaviour, understanding work flow, thinking about user convenience and applying logic is one way to deal with the situation. Also, relying on exploratory testing would be helpful in this kind of situations where requirements are not clear.
Most of time, it’s a good bet to prioritize user experience and convenience when requirements are not clear.
Method #2) Utilize experience:
Domain experience, overall testing experience, problems faced in past and personal insights can help address confusing situations and requirements.
Method #3) Refer wireframes:
Wireframes are a kind of visual requirement where you can find little details and those details can be very helpful in creating the expected picture of product or application and assists in covering testing aspects in a better way.
Method #4) Peer discussion:
No matter what the confusion is, if discussed with right bunch of people, things get clarified. Everyone carries different experiences, expectations, user eye and analysis view and discussing those poor requirements with peers will serve a benefit of crystallizing the understanding and boosting self-confidence.
Method #5) Clarification from customer:
Customer is the owner of the product/application and it’s always wise to approach him when it comes to clarity of requirements. But remember, it’s not advisable to attack the customer with 100s of questions. Before doing so, some homework is required.
Try to find out best practices available, understand benefits of implementation and then contact customer with question and possible solution.
Finally, loosely-defined or undefined requirements are a part of tester’s life and we need to accept them but let’s try to be optimistic and determine solutions to it. After all, we are testers, help keep the applications on track and guard them from falling flat. YAY to us :)
About the author: This inspirational post is written by STH team member Bhumika M. She is a project lead, carrying 10+ years of software testing experience.
Happy testing, as usual…..waiting for your views, comments and opinions.