How To Test Software Without Any Documentation?

This is a quite common interview question. It is common because it often happens in practice. Some feature was not well documented, people who were working on it left the company, there were no specific user guides, it was a legacy functionality, etc. It is a quite challenging situation for any quality assurance engineer. Being resourceful in such situation is the only way out. So how to test software without any documentation? Obviously the approach depends on the context. We will go through the list of possible places where you can find information about the software under test.

Explore me!

We start with the most obvious technique. This is the first thing that comes to mind when people ask themselves how to test software without documentation. You start with exploring the software and check how parts of it work. You are in a perfect position because you don’t know anything. Your perspective is not spoiled with knowledge about software under test. You may lack the domain knowledge for some proper understanding of business logic behind the software but because of that you should document all the things that seem strange to you and ask later for clarifications.

You can test the usability of the software, the functional design, user experience, performance and much more than that. In this phase there are no limits and no rules. Your only goal is to gather as many information about the software as possible. I admit, this can be a bit daunting because it may seem to you that you are progressing slowly. Remember that whenever you start doing something the initial steps are slow but the more you progress the more you feel satisfied.

Bug drive

Bug reports pose a truly valuable source of information. Some QA engineer created them in the past, which is a good thing for us. They probably hold a variety of information including steps to reproduce which drive us through the feature in question. If it was a good bug report, then it would contain also the expected result which also tells us about proper behavior of the software. In bug reports you can find also find attachments, videos, references to internal pages with some forgotten documentation or links to people who may have worked on this. All these are quite valuable information you can use to leverage your knowledge about the software under test.

Automation as a source of truth

I admit that projects which were poorly documented most probably don’t have any tests written, but as I mentioned the context matters. Since there is a remote possibility that some tests were written for the software under test we need to explore this possibility too.

We need to acknowledge that the automated tests depict pieces of working software. They display steps to prepare data for tests and usually go through the parts of the software in programmatic way. If the tests are written in any of the popular models for test automation you can fairly easy understand the logic under test. Unit and integration tests also provide information about functionalities but on a much lower level. This can be useful for finding edge cases. You can also see different paths through the code where you could use cyclomatic complexity. This can enhance your understanding of this software.

Documenting findings

The idea behind all of this is to make the project better than it was when we started this journey. To make it better we need to document the information we found. It would be the best to create test cases for all the tests we conducted and confirmed that this is how the software should work. If there were some discrepancies between our findings and the correct software functionality new bugs should be reported. New test cases ideally would be linked to tickets which were used to develop specific features. We can create a traceability matrix to have all the links between tickets and test cases in one place.

Conclusion

We all want to live in an ideal world where code is clean, all features are documented with up to date information, pipelines are fast and test hierarchy forms a perfect pyramid. In reality none of this happens and often we need to roll our sleeves and dig into a pile of… Learning ways to improve your position and at least have a plan about your starting point can give you enough of a boost to live through the day, one at a time. The above article provides some key points you should visit when you wonder how to test software without documentation. You may not have the chance to use the all of the above and I sincerely wish you don’t have to, but it is always good to be prepared. In the end it is important add value to the project by adding documentation of your own.