Step by step guide: Testing without requirements little requirements

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. Understand the difference between implicit requirements 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:

Explicit requirements:

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. Ask if this is a reliable source of truth or for 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. (You can also learn more about this at the BBST Foundations course that I’m a co-instructor of)

A few examples below:

6. Communicate your understanding to the people in your team

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!

For more tips on how to test against implicit requirements (e.g. “no requirements”) check out my eBook: Starting Your Software Testing Career