How to Deal With Bad Requirements as a Tester

In this article, we discuss in detail how to deal with bad requirements as a tester. Let’s get started.

Consider this scenario. A 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 it out, it was observed that the client never mentioned anything about duplicity of records in the requirements document and therefore no one asked relevant questions or thought about it.

How to Deal With Bad Requirements as a Tester

This was just an example.

In a career of more than 10 years, I have observed many numbers of cases where the 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 in detail.

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 this results in more work, more bugs from clients and more suffering for the project.

• How would you report an issue with a 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 an earlier published article – How to Test an Application without Requirements?

#2) Poor requirements – The quote, Knowing something incomplete is more dangerous than not knowing it at all, is very true when it comes to dealing with a poor requirement.

Interpreting poor requirements 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 searching.
• How would you interpret this – Forgot password should be implemented to facilitate user to regenerate/reset forgot password. Unknown about which workflow 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 the same time is just getting him/her confused and the system too is not an exception.

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

And that is how the bad, poor and conflicting requirements create hassles.

Being in the software industry should be part of the project as sometimes even the customer is not sure what exactly they want and how to word it.

From a 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 situation where requirements are not clear.

Most of the 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 the 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

No matter what the confusion is, if discussed with right bunch of people, things get clarified. Everyone carries different experiences, expectations, user eyes and analysis views and discussing those poor requirements with peers will serve the benefit of crystallizing their 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 the best practices available, understand the benefits of implementation and then contact the customer with questions and possible solutions.

Conclusion

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, helping keep the applications on track and guarding them from falling flat.

About the author: This inspirational post was written by STH team member Bhumika M. She is a project lead, carrying 10+ years of software testing experience.

Happy testing!! We are waiting for your views, feedback and opinions. Let us know in the comments section below. We would love to hear from you.