This section describes the frequently asked questions for the TestManager application.

1. How do I find out the location where Testcases are executed, so that I can use absolute pathnames to refer to my Testcase files ?

2. What happens if I invoke two TestManager programs concurrently ?

3. When using the RunExecutable Execution Procedure, the system is ignoring the ExeArgs property that I set, and always invokes my program with no arguments. Why is this ?

4. How can I refer to my input files within the Testcase execution. Should I use relative or absolute pathnames ?

5. How can I test my GUI using the Test Manager application ?

6. How do I extend the classpath for use within my custom procedures ?

1. How do I find out the location where Testcases are executed, so that I can use absolute pathnames to refer to my Testcase files

The sandbox for Testcase executions is specified in the testmgr.properties file. It is possible to modify this value if necessary.

2. What happens if I invoke two TestManager programs concurrently ?

This should not cause any problems, but if both instances are using the same workspaces, changes made in one will overwrite the changes from the other. If the two copies are using different workspaces then there will be no problems.

3. When using the RunExecutable Execution Procedure, the system is ignoring the ExeArgs property that I set, and always invokes my program with no arguments. Why is this ?

The early documentation for the application incorrectly gave the property name as ExeArgs. It should in fact be ExeArguments.

4. How can I refer to my input files within the Testcase execution. Should I use relative or absolute pathnames ?

The recommended approach is to use relative pathnames wherever possible, so that the TestSuite location can be moved on disk without requiring any property changes. Input files can be listed with a pathname relative to the root of the Input Files directory. For example, if I have a Testcase with an input file called "Run.exe" in a subdirectory "bin", I can use that file with the RunExecutable procedure by setting the ExeName property to be "bin/Run.exe".

Result files can also be specified using relative paths. For example, the ResultFile property of RunSQLQuery may be set to "output.txt". This file will be created in the root of the staging area when the Testcase is being executed. It will then be copied to the root of the ResultFiles area when the Testcase has completed. The same file can be used in the VerifyFileEquality verification procedure, by setting the Filename property to "output.txt".

There may be times when it is necessary to use absolute pathnames to refer to the Testcase files. This can be achieved by appending the location of the staging area on disk to the relative path. Using the example above, if the staging area is set to "c:/StagingArea", then the ExeName property may be set to "c:/StagingArea/bin/Run.exe"

5. How can I test my GUI using the Test Manager application ?

There are a number of commercial tools available that are focused on testing the user interface of an application. These tools are usually based around a capture-replay technique, meaning that the tool captures the user operating the interface, then replays the same actions each time that the testcase is executed. In order to verify the execution, a number of approaches are used, including the comparison of screen dumps, or tests for the presence of a dialog window, and so on.

Test Manager does not provide a capture-replay facility. It is possible to use Test Manager in conjunction with a capture-replay tool, because such tools usually store the user interface actions in a script, which is re-executed when the testcase is run. So the scripts may be stored as input files in Test Manager, then RunExecutable, or a custom execution procedure, can be used to invoke the capture-replay tool.

The capture-replay approach has its limitations, and these are well documented in the test automation literature. While the technique can be useful for quickly constructing testcases, it can be difficult to build good maintainable test suites using such an approach. It is often better to test the functionality of a system by targetting the "engine" of the system, rather than the user interface. In a typical three-tier application, this would mean writing testcases that exercise the functionality of the middle-tier components containing the business logic, by invoking those components directly, rather than indirectly testing them via the presentation tier. A tool such as Test Manager is ideally suited for this approach.

6. How do I extend the classpath for use within my custom procedures ?

When writing a custom procedure, it may be necessary to use other classes that may be located in jar files elsewhere. It may appear that adding these jar files to the Classpath property in Testmgr.properties will allow the classes to be used. Unfortunately this is not the case. That classpath is only used when loading the custom procedure classes themselves. The command-line used to invoke Test Manager will need to be modified, by adding the extra jar files to the classpath argument.