Technically there are no applications without requirements. Imagine software that does nothing specific but is simply line after line of code stretching on. It will be a staircase leading nowhere.
All software has requirements and is targeted at a particular task; specifically, it is a solution to a problem. So requirement-less software isn’t a possibility.
However, software without documented requirements is a reality that unfortunately most of us face more often that we like. The only thing worse could be that the documentation is insufficient, inaccurate or terribly outdated. Sadly, this happens too.
Honestly, there is really no substitute to a well documented functional/system requirement document with elaborate use cases and mock up screens. Although we have to admit that this is becoming a rarity in the industry due to rapid development cycles and a paradigm shift towards minimum or no documentation.
Therefore, this article is an attempt at some practices we have followed when we found ourselves in these situations.
Let us first look at a few reasons why there might not be documentation, to begin with:
These are all impediments that we testers have to bravely cross and emerge successfully. How exactly though, right?
Work with whatever little documentation you can get your hands on. It could be a basic simple backlog (in agile projects), a help file, an email, an older version of the BRD/FRD, or old test cases (check for these in your ALM tools and you might find them), etc.
Investigate, ask around and there is always some documented trial even if it is a thin one.
When this does not work out, do not discount your experience as a software user. For example, if you have to test a transfer operation for a bank account, no one needs to tell us how to do this, isn’t it? Because as online banking customers we all know that we need from and to accounts with a number of funds available to be transferred.
Agreed that not all situations are going to be as straightforward, but again, they might be too.
Use the older/current version of the application as a reference to test the future release of a software product. Now, I admit this is in negation to the rule, “Never write test cases using the application as a reference”. However, when we are working in a less than perfect situation, we have to mold the rules to fit our needs.
It helps to keep the following aspects in perspective when doing so:
Talk to the project team members:
Let us assume there is a shopping site where you can add items to the shopping cart. Ideally if there was documentation it needs to tell us how to add items to it, how many items can it have at a given point of time, what happens when the item that you have added suddenly goes out of stock, what is the maximum number of same items you can buy at the same time, etc. Our situation is that NONE of that is available at this time.
Apply method #1:
Find any documentation that you could. Ask your dev team if they have mock-up screens/look in the ALM tool or anything at all. If you do find something, that would be a good starting point. But if this method turns up nothing, then you can use your tester’s judgment/intuition.
We all know how shopping carts work so make your assumptions and arrive at few basic scenarios such as:
We can keep going on, but I am sure you get the picture.
Apply Method #2:
If there is an older version of the application available, this can be helpful in writing your test cases since you will have to write the exact steps of where to click, where to enter input, what to check etc. Screenshots/mockups/wire-frames – if available can be great substitutes too.
As you can see from the below screen, these things are apparent- the field names, the buttons or other elements present etc. (click on image for enlarged view)
Now, at this point testers do have some questions such as:
Apply Method #3:
Take your list of questions to the BA, Developer or the even the client and seek clarification. Once method 3 is done, you should pretty much be equipped with the all the information you will need to write detailed test cases and carry out your testing with as much confidence as you would when elaborate documentation was available.
Agreed that it is a lot more steps and a lot more follow up but to ensure Quality testing, these steps are inevitable.
In conclusion, all is not lost when documentation does not exist or is insufficient. There is still hope! Please share your experiences in similar situations.
About the author: This helpful post is written by our STH team member Swati S.
As always your comments, questions, and suggestions are most welcome.