How to Deal with Bad Requirements as a Tester

Being a Software Testing Engineer, we often meet a situation where the requirements are not good enough to complete the flow of any process.

Let me discuss a recent incident of my current project in which we are working on the last Sprint and we got a bug in the notification module which was a requirement of the third last sprint.

The project is an application for booking taxis with administration support. The notification for the driver approval has to be sent to the client as well as the administration of the app.

But currently, it is sending notifications to client-only and when the testing team has submitted a bug ticket to the development team then the developer acknowledged this bug to the tester, with the comment “it is as per client’s requirements”. But in a current sprint, the client is demanding notification from the administration.

So, in this situation, we have to perform regression testing on the last three builds. This is an example of bad requirements of the software products. In which, you may require to deal with a blocker or maybe a tweak in completing the flow of the process.

We have discussed an example of a bad requirement; Let us now discuss how to handle bad requirements. The Software Development Life Cycle (SDLC) starts from requirement gathering and analysis of the requirements.

Now for a requirement, it depends, how a client has asked for it, how the project leader got it, how the BA understood it, how a designer analyzed it, how a developer wrote code for it and how a tester receives it.

After gathering requirements, the very first thing to be done is requirement analysis. Before freezing all the requirements, the client’s requirements have to analyze whether these requirements are feasible or not.

There technical feasibility and cost feasibility should be considered while freezing the requirements. Based on these requirements BA should prepare use cases and wireframes to draw the flow of the process involved in the completion of the software product.

These documents should be sent to the client for approval; if the client approves or asks for any change then these changes should be considered. The finally approved documents by the client should be sent to the development and QA team.

The quality analyst then analyzes the wireframes and docs approved by the client.

If a QA gets a bad requirement then an immediate call (voice or video) should be made to the client in presence of BA to raise the alarm for that bad requirement.

A scrum meeting can also be made depending on the process that an organization is following. If the client approves that requirement as final then requirements should be freeze and should be handled with extra care after receiving the Software builds.

There are kinds of requirements that are specified by the client to be changed later in the project, these requirements are counted as CRs and should be analyzed properly.

The above discussion on requirements (Good or bad) come to the conclusion that before freezing requirements a complete analysis is mandatory both by BA and QA team.

Based on these requirements wireframes, flow chart, use cases, test cases and checklists should be prepared to filter out the bad requirements. Always remember, a bad or poorly analyzed requirement can block the road for a good Software Product.