Testing Zero documented Applications

Abstract

Being in testing domain, each one of us may come across a situation to test an application; which does not have any documentation.

What can we do in such situations? Can we say we cannot test the application, without having any documentation? Can we…? So, how to design test strategy for such an application?

This white paper tried to compile some methods that can be applied in order to design test strategy for applications which do not have any documentation.

Introduction

I was sometimes asked to test an application which has zero documentation. I guess the people working in testing domain will come across this situation time and again. In this document I tried to compile some means and ways that can be used /applied in such situations and will help in designing the testing strategy.

Background Being in testing domain, each one of us may come across a situation to test an application; which does not have any documentation.

What can we do in such situations? Can we say we cannot test the application, without having any documentation? We cannot do that…right? So, how can we test such an application?

Ask yourself the following questions

• Whether the application under test is a project or a product?
• Is there any other application available anywhere with same or similar functionality?
• Who has developed this application? Are the developers reachable?
• Who are the targeted users of this application? Can they be contacted?

Carefully note answers to the above questions as you find them.

Approach#1: Product with Zero documentation Step#1: Assume that the application you are asked to test is a product. In this case we can rule out the option of contacting the targeted users.

Step#2: So, try the other option we have, who developed this application? After some research (varies from couple of hours to a day) you identified that the people who developed this application cannot be reached.

Step#3: You feel like you are dead locked? Don't get frightened. We still have one more option; is there any other application available anywhere with same or similar functionality?

Step#4: Good god someone somewhere in the world created a similar product is what you found after some research on web. Bingo, you got a way out.

Step#5: Try to get any documentation that product has to offer or refer the help of that product to understand what that product does. Now, based on the knowledge you gained on the other product design testing of your parent application.

Example: You are asked to test a document editing software, whose functionality is similar to Microsoft Word. In this example you can refer to the Microsoft Word Help and get a feel of what is does and what it is used for.

Step#6: Based on the information you gathered, you can design testing of your document editing software.

Note: In case you found out that you are asked to test a product and you are not able to find any other product with same or similar functionality. What should we do now? Check the section Approach#3: Shelved Project with Zero documentation and try the approach mentioned there to design your testing strategy.

Approach#2: Old Project with Zero documentation

Step#1: Assume that the application you are asked to test is a project developed long time back and is currently used by a group of users. In this case we have a very thin chance of contacting the developers.

Step#2: Also, there is a very less chance of getting the information is there any other application available anywhere with same or similar functionality?

Step#3: Hmm…what are we supposed to do now? You identified that there are some users who are using this application. There you are!!!

Step#4: Contact the users who are using this application. Ask them to explain you what they do with this application. You can have a demonstration session with them. Ask them questions about the application. Make a note of the information they provide. Now, design testing of your application based on this information.

Approach#3: Shelved Project with Zero documentation

Step#1: Assume that the application you are asked to test is a project developed long time back and is not currently used by any one. It is kind of a shelved application.

Step#2: In this case we can rule out the options of contacting users, developer. Also we have minute chances of getting information about a similar project anywhere else.

Step#3: Gosh…all roads are blocked. What is my next step?

Step#4: Well, in this case we have to rely completely on our exploration and learning capabilities? Do you have the shades of a detective? Are you a quick learner?

Step#5: Install the application or catch hold of an environment which contains your application and you are allowed to play around with the application as well as the environment.

Step#6: Start hitting each and every button you see on the application, observe what is happening. Make a note of what you understand from that. I am tired of clicking the buttons…

Step#7: Now, for a change try clicking on all the menus and sub menus that are visible on the application and note down what is happening. In this way try to play around with each object that is available in the application and make a note of what you have observed.

Step#8: Ah!!! Now, I know what will happen when I do anything with an object on the application! Wait, I see some link between these items!! Seems like I can derive business scenarios or workflows from what I did in the application!!!

Step#9: Well done, design your testing as per the business scenarios, workflows you were able to extract from your exploration.

Note: The above approach can be tried for applicability for any other situation or scenario not covered in this document

Conclusion

Once you get an idea of the various objects existing in the application under test you can use all the testing concepts like Boundary Value Analysis (BVA), Equivalence Partitioning, negative and positive testing etc. to design the test cases. Also you can determine the scope of testing, types of testing to be done like functional, User Interface etc.

Now, you gathered handful of information by applying one of the techniques mentioned above. Beware not to repeat the same mistake what others did. The reason for me to write this whitepaper, Zero documentation!!!

Document whatever information you gathered during your research or exploration. Make sure to include the following items.

1. Purpose of the application
2. Targeted users of the application and what they do with it.
3. Business scenarios/workflows you were able to identify.
4. Complex areas of application, the areas to emphasize during testing.
5. Testing strategy you followed including types of testing you have done.
6. Any other information of importance you identified.
7. Any special notes or instructions you want to mention.

Do not forget to add a Note saying that the information mentioned in this document is purely based on your exploration and understanding.

If possible get this document reviewed by someone. If the review is not possible add another note to say that this is un-reviewed information in order to avoid any problems in future.

Hurray, you understood the application, able to design test strategy, produced some documentation. Kudos to you!!!