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.

software testing

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.

author_image

Kanika Vatsyayan

Kanika Vatsyayan is Vice-President – Delivery and Operations at BugRaptors who oversees all the quality control and assurance strategies for client engagements. She loves to share her knowledge with others through blogging. Being a voracious blogger, she published countless informative blogs to educate audience about automation and manual testing.

Comments

Add a comment

BugRaptors is one of the best software testing companies headquartered in India and the US, which is committed to catering to the diverse QA needs of any business. We are one of the fastest-growing QA companies; striving to deliver technology-oriented QA services, worldwide. BugRaptors is a team of 200+ ISTQB-certified testers, along with ISO 9001:2018 and ISO 27001 certifications.

USA Flag

Corporate Office - USA

5858 Horton Street, Suite 101, Emeryville, CA 94608, United States

Phone Icon +1 (510) 371-9104
USA Flag

Test Labs - India

2nd Floor, C-136, Industrial Area, Phase - 8, Mohali -160071, Punjab, India

Phone Icon +91 77173-00289
USA Flag

Corporate Office - India

52, First Floor, Sec-71, Mohali, PB 160071,India

USA Flag

United Kingdom

97 Hackney Rd London E2 8ET

USA Flag

Australia

Suite 4004, 11 Hassal St Parramatta NSW 2150