Sunday, February 20, 2011

Testing without requirements

It was one of the hectic days of my life. Concluding one of the meetings, I had just arrived for lunch at the cafeteria with one of my old friend (also a Test Manager). Looking at the bothered look on his face, I could not stop myself to ask “ Hey! What’s the problem? You seem to be very low”. “Anupreet – he said, how can I test without the requirements? How can my team design test cases, if they don’t even have a Requirements Document – forget about signoff? I have been pushed in a corner to start testing when there are no specifications.”

Believe me, this is nothing new. I do occasionally come across these situations and here is what I generally suggest to our testing fraternity:

At the onset – this seems to be a bit of worry – but believe me it sounds bigger than it really is…

Folks, there are ALWAYS requirements - even if they are not formally documented. They may take some time to discover and list, but they do exist. It’s your testing approach that helps you in finding those "hidden" requirements.

Step 1:
First, look for general requirements and work to document them. Some of these requirements come from previous versions of the application, some come from generally accepted usage. For example:
· The application must run on x, y, z platforms (perhaps because those platforms have always been supported)
· Must use abc database
· Must be able to process n trades / records in m seconds (forgive me for my investment banking terminology)
· Must be at least as fast as the last release
· Must be consistent with relevant laws, regulations or business practices
· Must not have any misspellings
· Must incorporate the company's usual look-and-feel
· Must be consistent
· Must not be missing any images
· Must not have any broken links
· Must basically work the same in all browsers which are officially supported by the company

Step 2:
Setup and conduct the interview the PM or technical developers and find out what they intend to do with this release. Document the intentions and use them as requirements. Ask them questions like:

- From where have the developers achieved their understanding of the system?
- Is there any kind of documentation other than functional specification?
- Do they have any technical documents?
- Anything else you can think of.


Step 3:
Stakeholders: Solicit input from anyone who is a stakeholder in the project. Share everything you find with everyone and revise it as needed. Ask them questions like:
- Is it a maintenance project or is it a new product?
- Is there a priority on any part of the functionality of the system?
- Are there known high-risk areas?

Step 4:
Look for the Help file or a User Guide for previous versions? If so, that's a good source of requirements.

Step 5:
Do Marketing / Sales materials exist for the product? Certainly the product should do what these materials say that it does.

Step 6:
Business Users: They are your lighthouse. Fix up meetings with them and be prepared with your questions. Ask them about any documentation they have – more specifically the one that documents business rules.


Note: Once the system is at all testable, do some exploratory testing. As you find "undocumented features", add them to the list of topics to be discussed.

Find out if the product is internally consistent. (This is an area I find to be very useful) Even if I know nothing at all about a product, I assume it must be consistent within itself, and within the environment in which it must operate.

Step 7:
Look for external standards within which the product must operate. If it is a tax or accounting program - tax law must prevail and generally accepted accounting principles must apply.

Ideally, all of these issues have already been considered and written into the formal Requirements documentation, which is handed to you. But if not, don't give up. Dig in and discover!

Last but not the least – remember your test strategy to be more scenario based followed by exploratory testing to uncover as many possible hidden requirements. What all business rules you discover should be documented to form a Business Rules Document and circulated to the BA’s / or end users to signoff and add any thing missed. By the time you cover all the steps above, you should be able to form a substantial base of requirements to be tested…

As I said above - Life is full on problems, it’s our approach that makes us a winner every time. Never say “This cannot be done”… but always “How can this be done …” and you will see things getting easier…

All the best!!!

Cheers
Anupreet Singh Bachhal
asbachhal@yahoo.com