How to deal with bad Requirements of Software being a Testing Engineer

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 notification module which was a requirement of the third last sprint. The project is an application for booking taxi with administration support. The notification for the driver approval has to be sent to the client as well as administration of the app. But currently it is sending notifications to client only and when testing team has submitted a bug ticket to development team then developer acknowledged this bug to the tester, with comment “it is as per client’s requirements”. But in current sprint the client is demanding for the notification to 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 software product. In which there is blocker or may be a tweak in completing the flow of the process.

We have discussed an example of 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 receive it.

After gathering requirements, the very first thing to be done is

Requirement analysis Before freezing all the requirements, client’s requirements have to analyzed whether these requirements are feasible or not. There technical feasibility and cost feasibility both should be consider while freezing the requirements.

Use Case preparation 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.

Document Approval These documents should be sent to the client for approval; if client approves or asks for any change then these changes should be considered.

Document Verification Quality analyst then analyzes

the wireframes and docs approved by 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.

Scrum set up A scrum meeting can also be made depending on the process what an organization is following. If 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 kind of requirements which are specified by client to be changed later in the project, these requirement are counted as CRs and should be analyzed properly.

ConclusionBefore freezing requirements a complete analysis is mandatory both by BA and QA team. Based on these requirements wireframes, flow chart, use case, test cases and checklist 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.