Example 4.4

 

Thoughts on Choosing the Right Tool:  TestComplete (Automated Testing Tool)

 

 

·         Real-world overview of what's involved in using the tool. 

·          Test Complete is an IDE environment that uses Delphi scripting to perform QA testing against an application.

·          Script projects can be individually selected and executed from the Test complete application.

·          Scripts can also be combined to create custom testing scenarios.

·          Utilities can be written to read and execute special test scenarios using “TestExecute”.

 

·         How the tool works

·          Include a unit from Test complete in the application which opens the application to test complete for interrogation.

·          Scripts consist of a collection of methods in a file called a unit, like in Delphi.

·          Scripts can be selectively turned on or off.

·          Script author can choose to get screen shot of any process or if an error occurs.

·          Script author can also send errors to anyone via email directly from script.

·          Scripts can handle unexpected dialog boxes, and can be directed to continue, or perform another action.

·          Tester can record a script for later playback during testing or to demonstrate a scenario that creates a problem in the application.

·          The recorded script can be enhanced via the built-in script editor for specific scenarios not encountered in the recording of the script.

 

·          What's involved in managing the process

·          The first thing that is needed is a breakdown of the application in to smaller components that can be created as projects in Test Complete.

·          This will allow selective implementation of each part of the application based on any set of criteria.

·          Script unit organization can be fashioned after the directory structure of the application source if it makes sense to do so.

 

·          How the tests are defined

·          The Designer can define what the scripts should evaluate.

·         Tests can be defined more specifically by the developer upon completion of the assigned task.

·         A developer could initially write the test script based on what has been implemented in code. A tester could then start from this base and add any additional test requirements to the script as needed.

 

·          How it integrates into Delphi and our daily build process

·          Test Complete could be executed from Finalbuilder after a build process completes.

·          There may be some way to implement only the new or changed scripts upon completion of the build process, so only what is new to the build is tested if there are available scripts for the new features.(Requires more research)

·          A standard set of base test scripts could be executed after each build to perform some preliminary test before testers run their scripts.

·          All the results can be reviewed after the build process to determine what actions to take.

 

·          What kind of technical knowledge is required to use the tool

·          Knowledge of Pascal.

·          General knowledge of Windows.

·          Some SQL knowledge would be helpful

 

·          Could we start with a small piece of our application?

·          We can start anywhere in the application.

·          The first thing should be the creation of a test plan to show the overall path to testing the application allowing a good measurement of progress.

·          Picking a module and creating test scripts for all of the major pieces in the module is a good place to start, and should be easy to measure progress that way.

·          Having several developers on a module or a few modules scripting for the major functionality, could also cut down the time to completion.

·          Once the major functionality is addressed in scripts, some of the smaller details could then be filled in.

 

·          Drawbacks to using the tool

·          There are some third party components that could not be referenced by the script. The latest version looks like it has addressed some of the third party problems.

·          There still may be a problem interrogating in-house components.

·          TestComplete can have problems running scripts that were not written by a tester or developer, but recorded on a different PC than the one the where script is being executed. What happens is that a script recorded at one screen resolution may not be able to perform the same at a higher resolution if the click methods generated are issuing a click event at a set of screen coordinates instead of on the object itself. This can be easily corrected most of the time by editing the scripts and removing the coordinates on the click event.

 

·          Benefits to the project of using the tool

·          More thoroughly test the application with each build.

·          Ability to perform stress testing using very little of the tester’s time.

·          Regression testing when there are architecture changes.