Writing Test Cases or Testing Without Requirement Documents

This post is all about learning how to test an application without requirements. Most of us come across articles without documented requirements but don’t know how to deal with them. This article will solve this particular issue.

Technically, there are no applications without requirements. Imagine a software that does nothing specific but simply consists of line after line of code. It will have no purpose.

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 than we like. The only thing worse could be that the documentation is insufficient, inaccurate or terribly outdated. Sadly, this happens too. What should you do in that case? Let’s find out.

How to Test an Application Without Requirements

Honestly, there is really no substitute for a well documented functional/system requirement document with elaborate use cases and mock up screens. However, 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.

Also Read

• How to test software requirements specification (SRS)?
• How to Create Requirements Traceability Matrix
• How to Review SRS Document and Create Test Scenarios

Let us first look at a few reasons why there might not be documentation, to begin with:

1. Shelved project being reopened
2. Documentation less format of working- Process
3. Documentation might exist- but might not be detailed or complete
4. Continuous releases and the older version related information has not been archived resulting in a gap in understanding of how the existing functionality reacts with the new one

These are all impediments that we testers have to bravely cross and emerge successfully. But how exactly do we do that?

Here are the top 3 methods to test an application without requirements

Method #1

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.

If this does not work out, do not discount your experience as a software user. For example, if we have to test a transfer operation for a bank account, no one needs to tell us how to do this. Because as online banking customers we all know that we need from and to accounts with a number of funds available to be transferred.

However, we do agree that not all situations are going to be straightforward.

Method #2

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.

• The application might contain bugs- so if after registration the system directly takes you to Screen1 (a certain hypothetical screen for the sake of our example) – Never assume that is the correct behavior. Also if a field takes alphanumeric chars and is a phone number- a question that and make sure you do not take the application as a granted example for expected functionality.
• In the above situations use your judgment and take the help of the application to give you a jump start, but be critical of it to question it’s working.

Method #3

Talk to project team members. You can:

• Offer to attend their meetings.
• Ask if you can participate in the unit and integration testing stages.
• If not, ask if the dev team can share their unit and integration test results.
• Arrange for a time for knowledge transfer at a convenient time.

Now, let’s apply the methods in an example

Let us assume there is a shopping website where you can add items to the shopping cart. Ideally, if there is 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, as well as what is the maximum number of same items you can buy at the same time, etc. Our situation is that NONE of those are available at this time.

Apply method #1

Find any documentation that you can. Ask your dev team if they have mock-up screens/looks in the ALM tool. 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:

• Items can be added to the shopping cart after being browsed or searched
• Once items are added to the shopping cart, the list of items should refresh
• The user should be able to continue shopping even after adding few items to the cart
• Adding the same item twice will cause the count of the items added to be incremented
• The items can be updated
• The items can be removed
• The total should be equivalent to the sum of the all the prices added
• Taxes should be calculated based on the zip code entered
• Shipping costs have to be added accordingly

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 screen given below, these things are apparent- the field names, the buttons or other elements present etc. (click on the image for an enlarged view)

At this point, testers can have a few questions such as the following:

1. What happens when I give a char in the amount box?
2. When do I add too many items?
3. What is the maximum no. of items this can take? Etc.

Apply Method #3

Take the list of questions to the BA, Developer or even the client to seek any clarifications. Once method 3 is done, you should pretty much be equipped with all the information you will need to write detailed test cases and carry out your testing with the same confidence as you would when elaborate documentation was available.

Agreed this requires a lot more steps and much more follow up, but these steps are inevitable to ensure quality testing, .

Conclusion

As you have seen in this article, all is not lost when documentation does not exist or is insufficient. There is still hope! You can follow the steps that have been mentioned in this article.

About the author: This helpful post is written by our STH team member Swati S.

Have you tried any of these methods before? Please share your experiences in the comments section below. Your suggestions as well as queries are most welcome. We would love to hear from you.