Testing Siebel Business Applications > Automating Functional Tests > Best Practices for Functional Test Automation >

Best Practices for Functional Test Script Development


The following best practices are provided to assist in your development of functional test scripts:

Comment Your Test Scripts

Use commented text in your scripts to describe the test steps. A test script that is thoroughly annotated is much easier to maintain. When sharing test scripts among a large team of testers and developers, it is often helpful to document conventions and guidelines for providing comments in test scripts.

Scope Variables and Data Tables for Script Modules

Make sure to scope script variables and data tables appropriately. The scope, either modular or global, determines when a variable or data table is available. By scoping them appropriately, you can be sure that the global variables are available across multiple scripts, and modular variables maintain their state within a specific script module.

The test tool typically allows you to store data values in tables and variables, but often these tables and variables have a scope that is defined by the test tool. You might need to override the scoping that is predefined by the test tool. Identify when variables are used within the script, and construct your test so that variables and data values are available when needed.

Include Multiple Validation Conditions in the Script

Use verification procedures to perform the function of the visual monitoring that the tester does during manual testing:

  • Checkpoints. Include object checkpoints to verify that properties of an object are correct. Properties that can be included in checkpoints are described in Functional Test Object Reference.
  • Verification routines. Include routines that verify that the actions requested were performed, expected values were displayed, and known states were reached. Make sure that these routines have appropriate comments and log tracing.
  • Negative and boundary testing. Include routines that perform negative tests. For example, attempt to insert and commit invalid characters and numbers into a date field that should only accept date values. Also include routines that perform boundary testing in fields that should accept only a specific range of values. Test values above, below, and within the specified limits. For example, attempt to insert and commit the values of 0, 11, and 999 in a field that should accept values only between 1 and 31. Boundary tests also include field length testing. For example a field that accepts 10 characters should be tested with string lengths that are greater than, less than, and equal to 10.
Handle Error Conditions

For critical scripts that validate key application functionality, insert validation conditions and error event handling to decide whether to proceed with the script or abort the script. If error events are not available in the test tool, you can write script logic to address error conditions. Set a global or environment variable on or off at the end of the script module, and then use a separate script module to check the variable before proceeding. Construct your test scripts so that for every significant defect in the product, only one test will fail. This is commonly called the one bug, one fail approach.

When an error condition is encountered, the script should report errors to the test tool's error logging system. When a script aborts, the error routine should clean up test data in the application before exiting.

Construct your test scripts so that individual test modules use global setup modules to initialize the testing environment. This allows you to design tests that can restart the application being tested and continue with script execution (for example, in the event of a crash).

Define Data Values with Structured Format

Some fields in Siebel applications require data values that have a defined format. Therefore, you must use data values that are formatted as the fields are configured in the Siebel application. For example, a date field that requires a value in the format 4/28/2003 02:00:00 PM causes an error if the data value supplied by the test script is 28 Apr 2003 2:00 PM. Test automation checkpoints should also use data that has been formatted correctly, or use regular expressions to do pattern matching.

Use Variables and Expressions When Working with Calculated Fields

Some fields in Siebel applications are calculated automatically and are not directly modifiable by the user (for example, Today's Date). Construct your test scripts so that they remember calculated values in a local variable, or in an output value if the calculated value needs to be used later in the script. For example, you might need to use a calculated value to run a Siebel query.

When you set a checkpoint for a calculated value, you might not know the value ahead of time. Use a regular expression in your checkpoint such as an asterisk (*) to verify that the field is not blank. When you are using a tabular checkpoint, you might want to omit the calculated field from the checkpoint.

Import Generalized Functions and Subroutines

Store generalized script functions and routines in a separate file. This allows you to maintain these pieces of script separately from specialized test code. In your test tool, use the import functionality (if available) to access the generalized scripts stored in the external file.

NOTE:  When developing and debugging generalized functions, keep them in the specialized test script until they are ready to be extracted. This is because you might not be able to debug external files due to test tool limitations.

Run a Query Before Adding a Record or Accessing Data

Before creating data that could potentially cause a conflict, run a query to verify that no record with the same information already exists. If a matching record is found, the script should delete it, rename it, or otherwise modify the record to mitigate the conflict condition.

Run a Query Before Accessing Application Data

Before accessing an existing record or record set, run a query to narrow the records that are available. Do not assume that the desired record is in the same place in a list applet because the test database can change over time.

You also should query for data ahead of time when you are in the process of developing test scripts. Check for data that should not be in the database, or that was left in the database by a previous test pass, and delete it before proceeding.

Manage Test Data from Within the Test Script

Create all test data necessary for running a script within the script itself. Avoid creating scripts that are dependent on preexisting data in a shared test database. Manage test data using setup scripts and script data tables, rather than database snapshots.

Remove New Records Created During a Test

Remove all records created by the test at the end of the script. This should be done at the beginning also, in case a previous test failed to complete the clean-up process.

You can implement the clean-up process as a reusable script module. For each module in the test, you can create a corresponding clean-up module and run it before and after the test module.

The general approach is to have the clean-up script perform a query for the records in a list applet and iterate through them until all of the associated test records are deleted or renamed. When the records need to be renamed, the initial query should be repeated after each record is renamed, until the row count is 0.

Exercise UI Components with Basic Mouse Clicks

When recording a test script, perform all actions using the visual components as if you were a beginning user. This requires clicking on the UI components rather than using keyboard accelerators and other shortcuts.

Most shortcuts in Siebel applications are supported for test automation. However, the Tab key shortcut is not supported—pressing the Tab key typically moves the focus from one control to another based on a preconfigured tab order. Click the mouse to move focus rather than using the Tab key.

Testing Siebel Business Applications Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices.