How to Deal With Bad Requirements as a Tester

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.

bad requirements

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 –

How bad, poor and conflicting requirements create hassles:

#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.

  • How would you report an issue about system crash when there is no definition of how the behaviour should be handled has been available?
  • How would you convey that loading time of 100 seconds for home page is unacceptable when there is no relevant requirement for performance?

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.

  • How would you confirm that the pop-up showing search results is valid or not when the only requirement mentioned was – search results should be proper and you are not sure which criteria should be considered while search.
  • How would you interpret this – Forgot password should be implemented to facilitate user to regenerate/reset forgot password. Unknown about which work flow the customer wants for forgot password, developer implements what he/she thinks is best and the conflicts start.

#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.

  • How would you test an application with requirements mentioned are as below :
    • Application should always open on home page.
    • Users are expected to sign in to access the application.
  • What would you decide the priority when the requirement document is as below :
    • The gaming application should promote user to next level if the user scores 1000.
    • User should be redirect to free subscription page once he scores 1000.

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:

Bad Requirements and how to handle them as a tester:

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:

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.

Read more => Wireframes – Should They Really Be Tested? And If So, How?

Method #4) Peer discussion:

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.

Related Post

Leave a Reply

Your email address will not be published.