What is requirements documentation? Something that everyone heard off but rarely seen. Especially in small dynamiq projects. Why is so? Because aspiring start ups don’t really have a clear definition of what is being made. The concept is there but the tools to achieve the goal might change a lot. So Question that arises is clear – can you successfully test the app if there is no documentation available?

Can you test without documentation?

The short answer is yes! It is not easy but we will try to explain how to do it properly so that you don’t end up with a software that is partially broken. The keyword here is standarisation and formalisation. Testing without documentation does not mean blindly clicking through the application. It requires more focus, more effort and simply more work to achieve a similar result as if the documentation and specification was present. 0.1 Gather the requirements Just in case… Before you go through the process of testing without documentation, please make sure that there is really no way to get the documentation straight. If no, then please follow my advices.

1. Interview

Focus on understanding the application as much as you can. How to do it? Gather all the information possible. I don’t mean the files only. Create a list of all the involved people. Ask Product Owner, Project Manager, Developers, other people who were part of the project. Try to contact end-users if they are available. Make sure you knock at every door.

2. Assess App goals

Write down all the business goals that you know or assume. See if you can think of any additional things that application needs to achieve? Create an overview of what the product is. This will help you in assessing the risks and keeping the focus on necessary actions only.

3. Brake down Functionalities

Go through the app. Look around. Verify what you have learned in step 1. The checklist is always a good idea. This time with the system functionalities. You do not have to get it right for the first time. Personally, I like to draw out the functions. Remember it is nothing formal. It just needs to help you investigate the different functions that need to be covered and how they relate to the business goals and to each other. Here is the example of how I do it.

4. Research the competition

The best way to know the requirements the end-user might have is to investigate similar solutions. Browse the web with the key phrases. Find businesses relating to the one you will test. This way you will know what a user can expect.

5. Analyze the risk

Do you know why you need to analyse the risk? Because part of a tester’s job is to minimize the risk in order to maintain high quality of the software. This also tells you where to focus your effort.

How to analyse the risk and importance? Create a risk matrix. First, decide which parts of the software are the most important in achieving the scope, and which are not. Mark them from 1 (not important) to 5 (the most important). Write down all the risks that might apply. Write down potential risks for each functionality and mark the likelihood 1-5 and impact 1-5. If you multiply it then you get the risk.

Please remember that even low risk functionalities in high importance part of the software need to be tested first! See the drawing before to check two different approaches – one table and graph.

6. Plan

Remember you have a limited number of hours and no formal reference. That is why you have to plan your actions. Do not spend the time by blindly clicking through the app and trying to remember everything you supposed to do. Your goal should be to cover at least the high risk items. Think of tests to perform. Write them down in advance.

7. Prepare the environment

As there is no time to waste, there is no time to start the testing and put it on hold because of some access and account issues. Make sure you prepare as much test data as possible to cover the planned tests. You are not alone in this. I’m sure developers will help you make some entries in the database. Make sure you have all the test data and all the credentials ready, before the start of testing. Prepare in such a way that once you start, you test. No unnecessary stops.

8. Formalise the testing

You need something to relay on when people ask you “where are we?”. Something to gather metrics, mark the progress, assess the state of the app. In a situation like this you can relay on less formalised documents like test charter. It’s a checklist on steroids that gathers all the items we mentioned above and let’s you easily check what has been done, what has been skipped and what is remaining. Please see an example of such a report below. Download the document

9. Execute

You made a good plan. Now it is time to execute it. Keep track of the time. Follow the schedule. Use the test charter as your checklist. Make sure to maintain the goal of testing . If something unexpected happens do not stick blindly to the planning. Simply adjust it and continue.

10. Exit testing

When do you finish the test run? When the exit criteria are met. There are multiple reasons like:

• Covering all scenarios
• Running out of time
• Major changes to the tested modules.

When you finalise the testing there are some deliverables to create. Lucky for you, the test charter has almost all of it. During the testing you’ve created bug reports using a project management tool. All the metrics are in the test charter. The test data is archived with it as well. Important thing is to not simply pass the data. Analyse it first! See if you can find bug accumulation spots (you can assume that 20% of bugs generate 80% of the errors and 1% of the faulty code is responsible for the 50% of the bugs). This info might be of help to Dev team. Share the findings with those who should be informed. It is always the best to work with full documentation and requirements. But we all know it is not always the case. In fact most of the time you will only find bits and pieces of the info you need.

That is why a skilled tester must be fluent in adjusting to such situations. We have to be strict and formal when it comes to stepping into the chaos of the application testing. Do not get carried away. Build your melodic. Follow it. Test.