A good way to address this problem is to build a "Model" of the test application.

The Test Lead "Application Model" is a hierarchical diagram that represents each of the functions that the test application provides, and where (in which part of the application) the function resides. The model consists of a number of "Folders" and "Components". A "Folder" can contain other folders and / or components, in much the same way that a directory in Windows Explorer can contain other directories and files. A "Component" represents the lowest level which you need to consider in your testing, and usually equates to a single function in the test application. A "Component" can occur at any level in the Application Model diagram, but the component itself can not contain other components or folders - in other words, it can not be further broken down into other functions.

Building an Application Model is extremely simple. You begin at the highest level and add folders that represent major function groupings in your test application. For example, you may add a first level "Folder" that represents each high level menu in the application to be tested. To add a folder or a component to another folder, just click on the "parent" folder to highlight it, and then click on "Add Folder" or "Add Component".

You may decide to build just a single Application Model, or to use different models for different parts of your Application. It is often easier and more convenient to use separate models for items such as installation programs, for example, which are really completely independent of the main test application.

Using the "Demo 1" template, an Application Model can be built at any time prior to creating a Test Plan. Because the process of building the Application Model helps you to establish a clear view of each function that you will need to test, and also helps in identifying how critical that function is in the normal day to day running of the application, we like to create Application Models as the first step in any testing project, even before creating the Risk Register. This helps to ensure that risks associated with obscure or infrequently used functions are not overlooked, and can also help provide some structure when building the Risk Register if you are fairly new to the risk assessment process.