Is it possible to perform testing without any requirements?

Being asked to perform testing on a piece of software without a requirements document is something that should rarely occur. After a conversation with the customer to establish their unique needs, one is prepared and the process of development begins with the requirements as the foundation.

However, depending on various variables such as the company you are in, the customer you are delivering to. Or even the software that you are delivering. A set of formal requirements might not be available or even required. Making testing seem that much more complicated. Or even impossible to begin. But with the right planning, and reflection on past testing processes. You can implement a strategy that is not only appropriate. But also targeted and highly effective.

Start with a plan

You first off need to start off with preparing a plan of how you intend to perform testing. This will not only be a valuable asset for training and reflection. But also a crucial artefact to remind yourself, or anyone who needs to know, what testing activities took place.

When drawing up a plan, I recommend the use of back-wards planning, (or back-wards goal setting). Instead of writing down the steps you need to take to reach your eventual destination (in this case, successfully completed testing of a piece of software). You instead write the goal down first and then work backwards from that. Each step focused on achieving the knowledge or skills you need to reach your next step and ultimately the end result.

Speak with the project manager and the developers

You may be able to gather some details from colleagues or communications to help you establish the purpose of the software you will be testing. But these are likely to be hollow and incomplete, with lots of holes and unspecified information.

To help you fill in your knowledge. Don’t hesitate in this situation to seek out the project manager and ask them any questions that you might have in a one on one setting.

• How will the application be used?
• What is its purpose?
• Is there any specification information that I should know?

These sorts of questions will not only help to identify areas of risk that you may want to focus on in your testing. But they will also enable you to make fewer assumptions about how the software works.

Some assumptions we make are perfectly valid. For example, If I click on a button to add an item to my cart in an e-commerce application. I assume the quantity of the contents will go up by the number of items I have added.

But if we make an assumption about valid inputs/outputs of an API endpoint, for example. Then wrongful assumptions will lead to lost time with incorrect bug reports being created and avoidable confusion for our team members.

Also, make sure to include the developers in your initial investigation. They will provide valuable technical insights that you won’t be able to get elsewhere.

“The Best Predictor of Future Behavior Is … Past Behavior”

The next thing to consider is whether you have tested any other software that is similar to the one you are now facing.

• How did you approach that project?
• What ‘unknown unknowns’ did you encounter?
• What did you learn from that project?

It’s also possible that the software release is one that is compiled purely of previously discovered bugs or failed test cases. In that situation, you can refer back to previous documentation or bug reports to give yourself a better idea on how to move forward with your testing.

Use exploratory testing

Using exploratory testing techniques in a situation in which there is little documentation is the perfect tool to deploy to maximise your testing effectiveness. It will allow you to only gather knowledge of how the software works through experience and discovery. As well as enabling you to verify if it meets the expectations of end-users.

I have written about exploratory testing here and here and encourage everyone to read those articles if they want to learn more.

You can’t test everything

Overall, you need to keep in mind that while targeting your testing efforts on the key areas identified in previous steps. Or by following an extensive plan that you have constructed with developers or project managers. It is important to remember that you can’t test everything, and it is critical to communicate that point to stakeholders as well.

Not having a requirements document to refer to will create a lot of unknowns for testers. And even though we are fantastic at identifying them and taking them into consideration. There is a limit to our abilities and missing out on key documentation is never ideal.

• Category: Software Testing