Just like life, you may at times end up testing an application that has not been developed as per approved requirements. In fact, I have come across scenarios where business has provided some broad outlines and developer has gone ahead and applied his/her own interpretation of the requirements.

The beauty about waterfall method of SDLC is that you know exactly what the requirements are. You would have had a BA conduct workshop with business sponsor and business SME to document the main requirements. You would have had both BA and Solution Designer conduct workshops with SMEs to finalize the requirements and technical details. The Business Requirement Document (BRD) would have been baselined and approved by business and all stakeholders. So you would have had an alleged completed and approved requirements document that a tester can follow. I say alleged because there have been instances when BA has done a rather poor job in documenting the requirements. It is at that point you find out what you are testing does not match with what the BRD states. Then it becomes a test driven development and people start escalating. Testers start escalating to Test Manager that application doesnt match with requirements. They start raising defects. Developers then start becoming defensive and start rejecting defects from testers because this was not documented in BRD and hence their interpretation is quite different from that of a tester. BA, of course, starts pointing finger at the business who did not specify all these requirements in detail and we start having groups going at each other. Poor business! All they wanted was to make the customers happy and now they find themselves at the core of the blame game!

So yes, waterfall method, despite all its benefits, also has some clear shortcomings. If you go and ask any tester what method they would prefer, the majority will reply that they prefer the waterfall method. It is because you do not have to do much exploratory testing. You have clear sets of requirements against which you test the application.

However waterfall method is clunky and the entire process may take 6 to 12 months to complete.

In recent days, I have had to deal with a project that inherited some APIs from an older project. There were some obvious flaws in the original project testing (before my time at the organization). So there were some known issues with that API. A later project then adopted that API. However because the defects were classified as known issues, the later project never resolved them. Hence we come to the current project I am dealing with.

Since this project has adopted that same API, a number of design flaws have become inherent to the new application. It infact got amplified by the new application. Also the fact that the API has been inherited, there is not much documentation about its requirements. Which brings me to the current topic.

One thing I always tell my team:

SDLC is a collaboration.

Business has a requirement and it is the responsibility of IT to deliver this to business. How the new application/service will look and behave is completely dictated by the business. We only provide the technical know-how about how to design that application/service. In that sense, if there is conflict between dev and test or between dev/test and BA or dev/test and solution designer, then the project is likely to suffer.

As a Test expert, your role is to provide direction/guidance. If you can grasp the concept that we are only there to facilitate some application/service for business, then it should be amply clear to you that we have to work with BA, Solution designer, development team and the PM, collboratively.

So when faced with an application that has very little documentation about its requirements, you need to take the following steps:

1. Run basic black box testing – to understand the core functionality of the application
2. Try to find out defects/Issues with the application/service and log these in a defect tracking system
3. Discuss with BA, Solution designer and development team if these are defects or gaps in requirements
4. Ask the development team to comment on these defects/issues
5. Then ask the BA to document these requirements in a 3-4 page document (no need to go for a big bang BRD)
6. Use this small requirements document to complete testing

You will often experience that certain functionality requires further clarification from business. As you are discussing the functionality, do not be shocked if business turns around and says that the requirements are wrong and the solution is wrong. It can happen at times!

Do not get angry or frustrated. Business has every right to change their mind. It is their money! We only provide the technical know-how and SME expertise to deliver the application/service to business.

So bottom line: as a test expert, you should be ready to test an application/service with or without clear requirements. Things start to become more challenging and interesting when solution is provided without much requirements. It is then you will find the true measure of being a test expert.