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:
- 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
- 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. 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.
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 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!
- My blog post on My Most Used Test Heuristics
- Testing Without A Map
- BBST Software Testing Courses (The consistency heuristics you learn in this course are VERY useful for testing without requirements)
For more tips on how to test against implicit requirements (e.g. “no requirements”) check out my eBook: Starting Your Software Testing Career
📹 If you enjoyed reading this post, check out my YouTube channel and subscribe.
I post videos that can help you with your software testing career.#Agile #Exploratory Testing #Popular #Starting in Testing #Testing