1. Testing Business Applications Guide
  2. Overview of Executing Siebel Functional Tests

Overview of Executing Siebel Functional Tests

The process of executing Siebel functional tests is designed to provide for delivery of a functionally validated Siebel application into the system environment. For many customers the Siebel application is one component of the overall system which may include other back-end applications as well as integration infrastructure and network infrastructure. Therefore, the objective of executing Siebel functional tests is to verify that the Siebel application functions properly before inserting it into the larger system environment.

Application developers test their individual components for functional correctness and completeness before checking component code into the repository. The unit test cases should have been designed to test the low-level details of the component (for example, control behavior, layout, data handling).

Typical unit tests include structural tests of components, negative tests, boundary tests, and component-level scenarios. The unit test phase allows developers to fast track fixes for obvious defects before checking in. A developer must demonstrate successful completion of all unit test cases before checking in their component. In some cases, unit testing identifies a defect that is not critical for the given component; these defects are logged into the defect tracking system for prioritization.

Once unit testing has been completed on a component, that component is moved into a controlled test environment, where the component can be tested along side others at the module and process level.

The following image illustrates the process of executing Siebel functional tests.

Execute Siebel Functional Tests Process

As shown in this image, there are three phases in the process of executing Siebel functional tests:

  1. Unit test. The unit test validates the functionality of a single component (for example, an applet or a business service). Typical steps involved in unit testing include the following:

    1. Execute unit test cases on a given (completed) component.

    2. Perform configuration or scripting review.

    3. Regarding defects:

      • Fix critical defects that must be fixed, and return to step a.

      • Log and track other defects, if there are any, and continue to step d.

    4. Check in unit tested component.

  2. Module test. The module test validates the functionality of a set of related components that make up a module (for example, Contacts or Activities). Typical steps involved in module testing include the following:

    1. Migrate the (unit tested) component to a Test environment.

    2. Execute module test cases on the component.

    3. Log and track defects if there are any.

  3. Process test. The process test validates that multiple modules can work together to enable a business process (for example, Opportunity Management or Quote to Order). Typical steps involved in module testing include the following:

    1. Execute business process test cases on the component.

    2. Log and track defects if there are any.