How to Test an Application without Requirements?

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 like a stair case 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.

test without requirements

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 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:

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 successful. How exactly though, right?

Here are 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.

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 needs from and to accounts with the amount of funds available to be transferred.

Agreed that not all situations are going to be as straightforward, but again, they might be too.

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 mould 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- 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 the project team members:

  • 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 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 give 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:

  • Items can be added to the shopping cart after being browsed or searched
  • Once I add items 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/mock ups/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)

test without requirements

Now, at this point testers do have some questions such as:

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

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 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 author: This helpful post is written by our STH team member Swati S.

As always your comments, questions and suggestions are most welcome.

Recommended reading

24 comments ↓

#1 karunanidhi

Its really very useful site for software tester to familiarize for themselves.

#2 Thanh

Hi Swati,

Thanks for sharing. Many valid points.

Btw, I also would like to add that there’s a difference between Requirements and Documents. Of course, we can test without Documents, but without Requirements we hardly test the system because we don’t know what’s expected.

what’s your thought?
-Thanh

#3 Sandeep Fofandi

This is very useful site..
Today this topic is very importance having 4+ year experience i faced this question most of time.

Always Helpful… :)

#4 Rahul

Hello I’m new to load testing. In my test case, I have 8 HTTP Requests and I want to add 2 seconds pause between each request and then automatically increase the number of users on repeating the test case. I don’t understand how to do it PLEASE HELP

#5 fathima

We can still work on by reading whitepapers,user guides and competitive projects in same domain … Only problem is make dev team to understand to importance of adding the new feature.

#6 vishalmaske

Hiiiiiiiiii……………..
thanks to u r help…………..this is something else……very understanding……..and it helps us every time when we faces the problem related to testing…..

#7 Ahmed Fathi Elgaly

Really so good solution, but without requirements you can deliver any thing, so the requirements is so important.

#8 Swati Seela

@Thanh: Totally agree. Requirements are inevitable and without them neither the building nor testing can happen..requirement Documentation on the other hand may or may not always be mandatory…Thank you for bringing it up.

#9 Swati Seela

@All: thank you for stopping by and letting us know that this article has been useful.

#10 Divya

I faced the same situation many times to test an application without any documents. Initially i got frustrated. Later i am used to it.
First i take KT from the developer/lead who has sufficient knowledge, then i note down. I just write rough test cases. After that while testing whatever doubts i get regarding the behavior/expected behavior, i used to ask them…. Thanks for sharing the article…

#11 Gunasekaran V

Once I faced this challenge where the application (Main Frame) was operational for years and when the client wanted to migrate to new technology, we have to document the requirements. The available requirements are very cryptic and unless you run through application many times, you can not understand the functionalities. Good article

#12 Gaurav Khurana

First thing is we should ask from domain experts if available.
We should try to get some user case diagrams.
Try to understand the flow of system
Things explained above are more towards the exploration
write end to end flows and then confirm with dev/BA if that is what the expectation is.
Use the system to understand the flow.

#13 Swati Seela

@Gaurav: You are right. We were only trying to explore the situation when there might not be any user case diagrams or anything else to fall back on.

Thank you for sharing your thoughts!

#14 Nagaraj Mamedi

Above topic on testing without documentation is very helpful, we faced similar situation and as advised its alway best approach to refer old documentation and get in touch with dev and Business teams to adept to product feature quickly before we begin our testing..

#15 manju

Useful information Thanks for sharing

#16 Swati Seela

@Nagaraj Mamedi: Thank you for sharing and reinforcing our concept! we appreciate it…

#17 jyothi

hi….
do u have any projects so that one can get full idea about the testing………if u have plz mail me…

#18 akriti

This website is very helpful and this particular example of e-commerce was very useful for people who don’t have domain knowledge on e-commerce.

#19 Prakash

Very Helpful article……..

#20 dfgdfg

This website is very helpful and this particular example of e-commerce was very useful for people who don’t have domain knowledge on e-commerce.

#21 Nagarjuna

Thank you Swathi… for such a detailed description and examples. Keep it up the excellent work…:)

#22 Sonali

Hi ,
I had a query.
What if the only document provided to the tester is only an old user manual, in that case , how to write test cases with full coverage . Here the application is a desktop application and we are being provided with no requirement documents even after lot of requests.

And also, should all the bugs reported while exploratory testing be written in form of test cases ?

TIA-
Sonali

#23 Cukici

hi…

Great points here. Aw, if documents and requiments are always updated, so testers need all concentration to be notice about this point.
I just want to add this point here… :D

#24 surya ps

hii

Leave a Comment