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.

Recommended Reading

20 thoughts on “How to Deal With Bad Requirements as a Tester”

  1. Very good article. I am going thru the same problems related to NO Product Requirements and it is expected that the product is 100% bug free. :P

  2. this is nice article about how to deal with bad or incomplete requirements.but we never forget the role of
    Exploratory testing along with good experience.
    if we try to include some experience tester or developer that time so we can easily handle this situation in client meeting.

  3. Really it is so nice article for the beginners I think, but what about focus for articles for experienced Quality Member

  4. Utilize experience: that diagram is really very nice

    Refer wireframes: is also a good way to avoid some problem.

    Preparing a checklist would also help you in avoiding various such aspects of a product. In above example duplicate

  5. very good one….bad requirements always leads to a bad product.

    Exploratory testing is always a good thing that every tester should follow.

    Thank you..:) for the good article…

  6. The points you clearified Bhumika are so useful and those problems we really getting while doing every project.
    Thanks for info. Keep it up. :-)

  7. This is really a good article. Exploratory testing always good for all the QA person and always give one more step ahead to testing the application.

    Thanks for posting such nice article.

  8. Wow….the knowledge/experience diagram tho!!!!!!!!!!!!!!!!!!!!!!….God bless you for writing this article!!! Im inspired!

  9. Hii
    Good Article.

    I have a general doubt.
    As i working in Agile methodology,specifically SCRUM. We as a team of Programmer and Tester (Development Team) so sprint planning and thus the SRS is Shared to all at a same time.
    If you say there are ways to handle the poor requirement. is it really a part of testing ?
    In my scenario (also in most of Sprint cases) QA Task starts after Developer Task end (this is entry criteria for testing phase) so, i think all here – THE MOST IMPORTANT and BENEFICIAL way to handle poor Requirement (PBIs) in Scrum environment is to know “HOW DEVELOPER ARE IMPLEMENTING THIS FEATURE”.

    Plz share your thoughts on this –

  10. Requirements hold keys to Software Testing. Requirements are directional and must be clearly written and correctly carried out
    David A

  11. @Avinash, @Rakesh, @Sangram Kumar Das, @David, @Tapas and all other readers,
    I am glad that the post was helpful and well-received.

    @Ajay and @Gaurav,
    Thank you for your continuous readership with us.

    I will respond soon.



Leave a Comment