Step by step guide: Testing without requirements little requirements

2020-12-22

Agile Exploratory Testing Starting in Testing Testing Popular

If you haven’t already, you may one day find yourself in a project where there are no (explicit) requirements or very little requirements to go off.

Software can be created from conversations and assumptions. People may also assume that the little requirements they do write is enough to easily code against or test off, but then you later realise that the few lines that have been written actually pose more questions than provide answers.

You first time testing on a project without requirements can be a bit scary but I’m hoping this step by step guide will help you.

1. What is the difference between implicit reqiurements and explicit requirements?

There are ALWAYS implicit requirements. But there aren’t always explicit requirements.

An implicit requirement is a requirement on the SUT (Software Under Test) that is not explicitly stated somewhere (e.g. in documentation)

An explicit requirement is a requirement on the SUT that is explicitly stated.

Some potential examples:

Implicit requirements:

I’ve found generally browsers like Chrome and Firefox are expected to be supported and this might not be stated.
That useful error messages show to the users so they can recover

Explicit requirements:

That only a user with certain permissions can do certain actions
Performance - how fast should a page load for example?

2. Ask for the requirements or documentation

It might be obvious, but it’s good to see what written documentation you have to go off for your testing

3. Is there a reliable source of truth or other oracles?

Is this actually what you can expect? Maybe it’s outdated or people have forgotten to update it?

At this stage you can also ask if there is someone who knows how the expected behaviour should be. This person would be one of your oracles.

Here is my blog post on my most useful test heuristics

4. Ask if there are any designs you can look at

Designs are a great way of not only understanding how the SUT is expected to behave, but also how the designer in your team interprets the implicit requirements or little requirements

5. Document your understanding of what should happen

Now based on the information you have, document your understanding of what should happen and be prepared to back it up. (You may not have to explain yourself, but it’s good to be prepared with your reasoning/proof, should someone ask you why you have certain expectations)

A great way to come up with some ideas on what should happen is to use consistency heuristics.

A few examples below:

Supported browsers - Some browsers are only available in certain markets. e.g. QQ in China (websites like Statcounter has information on this)
Mandatory fields - In general, mandatory fields are marked to show the user that they are mandatory
Mobile testing - Offline support. What happens if the user goes offline? You can check comparable/similar apps to see how they handle users having their internet drop

6. Communicate your understanding to the people in your team

Be sure to state that it is your understanding/interpretation of what should happen
Be explicit and specific
Use examples if and where possible

Once there is a shared understanding of the expected behaviour, share this information with your team.

7. Hands-on testing!

Whether you like to write and execute test cases or create test charters and use those - now’s the time to get to know the SUT a little bit better!