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 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 than 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.

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.

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.

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

About the author: This helpful post is written by Swati S., (Software Testing Help team member)
This is the link to the full article

Leave A Comment

At vero eos et accusamus et iusto odio digni goikussimos ducimus qui to bonfo blanditiis praese. Ntium voluum deleniti atque.

Melbourne, Australia
(Sat - Thursday)
(10am - 05 pm)
Puede darse de baja en cualquier momento siguiendo el enlace para darse de baja de nuestro boletín. Para saber cómo gestionamos la privacidad de los usuarios, consulte nuestra página.

Déjanos tus datos

Déjanos tus datos
es_ESSpanish
Abrir chat
¿Necesitas Ayuda?
Hola,
En que podemos ayudarte!