A.: With TestComplete you can test any Windows application through the application's UI. Script routines simulate mouse movements, clicks, key presses and other user actions through Windows messages. This way of testing does not depend on any compiler. It is called functional or "black box" testing.

For Web pages and for applications created with Delphi, C++Builder, Visual Basic, Visual C++, Java and .NET compilers, TestComplete provides access to methods, properties and fields of the application objects. Scripts can even access protected and private object fields. For more information about accessible object elements and about Open Applications, see the "Open Applications" topic in TestComplete's help.

Note that testing of Java and .NET applications is supported by two plug-ins specifically designed for this purpose. These plug-ins come with TestComplete Standard and TestComplete Enterprise. Web testing is only supported by TestComplete Enterprise.

A.: Regression testing means this -

• Test your application until the tests come out clean.
• Add something to the tested application.
• Design a test for features added to the new build.
• Now, run all old and new tests over the new build.
• Fix and re-run until everything is clean.
• And so on.

Basically, this means that at least one test script is added (calling other scripts as needed) to each new build. Then, a call to this test script is added to MainScript -

Sub MainScript
  Test001 'Test features of the build 001
  Test002 'Test features of the build 002
  . . .
  Test123 'Test features of the build 123
End Sub

Both the old and new tests should pass without errors. If there are errors, you keep fixing and testing. You can use whatever numbering system you want for builds. One system is to use the integer parts to indicate new functionality, or rebuilt functionality, and the decimal part for fixes meant to meet the same tests. For iteration 123 in the regression testing, you would first test Build123_0, and perhaps reach Build123_7 before you start to work with Build124_0, with a new script added to MainScript -- TestBuild124. There is more information in a whitepaper about regression testing at: http://www.automatedqa.com/techpapers/regression.asp. You may also find other helpful information about this subject here: http://www.extremeprogramming.org/.

A.: TestComplete includes two plug-ins that can be used for distributed testing: HTTP Load Testing and Network Suite.

The HTTP Load Testing plug-in allows you to test client-server applications that communicate using HTTP or Secure HTTP (SHTTP). TestComplete can simulate up to 300 virtual users on each computer involved in testing. If you are interested in this approach, please read the "Testing Web Servers Using the HTTP Load Testing Plug-In" help topic. It includes links to other help topics, for example, the "Using Groups of Virtual Users" topic that contains script samples.

The Network Suite plug-in performs distributed testing of the server application through the GUI of a number of client applications. You can simulate as many users with as many computers that are involved in the testing process. The client application will be launched on each of the computers and the script on the master machine will control the activity of every client. Please see the "Distributed Testing" help topic for details.

A.: Support for Java and .NET applications is provided by special TestComplete plug-ins: Java Client and .NET Client. They are included in both the Standard and Enterprise versions of TestComplete 3.xx. Everything mentioned in this FAQ and the TestComplete help system is true for Java and .NET testing.

The Java Client plug-in provides specific files that allow you to create and test Java Open Applications. That is, being compiled with these files your application opens its internal elements to TestComplete. For Java applications that means access to public, protected, private and packaged methods, properties and fields. Java Open Applications can be built with any development tool that supports one of the following Java virtual machines:

• MSVM, build 3309 or later.
• Sun JDK (or JRE) v. 1.1.8 or later.

For instance, you can use Microsoft Visual J++ 1.1 or later, Borland JBuilder 3.0 or later, Sun Forte 1.0 or later, and so on. The AWT and Swing library classes are also supported.

The .NET Client plug-in provides TestComplete with the ability to access internal objects, methods and properties of .NET applications without recompiling them (if the Microsoft .NET Framework v. 1.0.3705 or later is installed on the given machine). That is, this plug-in make .NET applications always “Open” to TestComplete. Your scripts can get access to public, protected, private, internal and private internal properties and methods.

A.: Both Microsoft Visual Studio 2003 and Visual Studio 2005 let you create, run and debug Windows CE applications targeting the Microsoft .NET Compact Framework. For further reference, we will call them Windows CE .NET applications. To run these applications under a Win32 platform, you can either use the Windows CE device emulator (which is built into Visual Studio), or run the application as a Win32 application (provided that you have Microsoft .NET Framework v. 1.0.3705 or later installed on the given computer).

If you manage to run a Windows CE .NET application under Microsoft .NET Framework, you will be able to test it with TestComplete like you test any ordinary .NET application, which are meant to be run under the Microsoft .NET Framework. Testing Windows CE .NET applications requires the .NET Client plug-in. It makes the given .NET application “Open” for TestComplete and thus provides access to the application’s internals (objects, methods and properties). See the answer to the previous question.

If you are testing a Windows CE .NET application that was compiled under Visual Studio 2003, the application’s objects do not have names at run time even though they were specified at design time. This problem doesn't exist in applications built with Visual Studio 2005. That is why it is recommended that you compile your Window CE .NET applications in MS Visual Studio 2005 before testing them in TestComplete.

A.: Yes, you can record and run TestComplete scripts that simulate user actions with grid controls. To learn more about this, see Working With Grids in TestComplete 3 or Grid Samples for TestComplete 4.

A.: Yes, TestComplete can simulate mouse clicks, key presses, and so on, within the console window. However, these applications cannot be tested as Open Applications.

A.: The 30-day trial version of TestComplete includes all the features available in the registered version, with a 2 unit/500 line script code limit.

Note that TestComplete's trial version is an Enterprise version. Therefore, the difference between TestComplete trial and TestComplete Standard is significant.

A.: Please contact sales@automatedqa.com and request a trial extension.

A.: You can execute scripts via TestExecute in one of two ways: from the command line or by running TestExecute and selecting the needed project from its menu. In the second instance, the application icon is displayed in the system tray and you can invoke the application menu by right-clicking the icon. There are five items in the menu: Run, View Results, Edit, Stop and Exit. The first three items bring up the menu where you can select the corresponding file (.mds if you need to run a project, .htm - to view results via Internet Explorer and .mds, .pjs or unit (.sd, .sj, .svb, .scpp) files if you need to edit scripts), the Stop item stops running the script, the Exit item closes TestExecute. To learn more about running TestExecute from the command line, please read the "Command-line Arguments" help topic.

A.: TestExecute is a "re-distributable" product and is licensed per distributed copy. This means that whether you install it for yourself or distribute it to an end-user, you must obtain a specific license for each distribution.

TestRecorder is a component which can be embedded in your application and as such, there are no royalties. You must however purchase a license for all developers who will be using the product.

A.: Please, visit http://www.automatedqa.com/downloads/plugins.asp.

A.: You can obtain the exception call stack: Compile your application with the debugger information and run it under TestComplete using the DbgServices object. If an exception occurs, TestComplete will post the call stack to the log. See also the "DbgServices Object" help topic and try the <TestComplete>\Samples\Scripts\DbgServices example.

There is another way to find the call stack: Compile the application with debug information, run it under the Exception Trace profiler in AQtime and then launch a TestComplete script. If an exception occurs, AQtime's Event View panel will display its call stack.

A.: Yes, you can. Both TestComplete Standard and Enterprise include the DLLAccess plug-in that lets you call any stdcall function from 32-bit dynamic link libraries. Before calling a function, you should perform a number of preparations: load the desired DLL in memory, define parameter types, and so on. All of these steps are described in full detail in TestComplete's help: just search for DLL Object in the Index tab.

Another plug-in, dotNETBridge, is also available in TestComplete Standard and Enterprise. It lets you call functions that reside in any .NET assembly (it can be an assembly supplied with the .NET Framework, as well as an executable or a dynamic link library of your or third-party .NET application). Before calling a function from the desired .NET assembly, you should add this assembly to the assembly list stored in the References option (Engine Options | dotNETBridge). To learn more about this, see the "Calling Functions From .NET Assemblies" help topic.

A.: TestComplete does not have special support for PowerBuilder applications: it does not recognize controls inside data windows and it is not possible to make a PowerBuilder application an Open Application. You can only test these applications in black box mode.