Siebel Business Process Framework: Task UI Guide > Scenario for Developing a Task UI > Example of Developing a Task UI >

Testing the Task UI

This task is a step in Example of Developing a Task UI. The application developer begins with unit testing.

Unit Testing

Siebel CRM displays the Submit Expense Report link in the context pane. If the user clicks this link, then Siebel CRM displays the first view of this task UI. The application developer is excited, but this joy is spoiled by the fact that the developer failed to include an Expense Description field in the Expense Header Applet. Several iterations later, the developer demonstrates the submission task UI to the business analyst, who is pleased, but who also notes that there are a few details that require refinement. Finally, version 16 of the submission task and version 22 of the SRF is ready for integration testing.

The review task UI is more difficult to unit test because it requires tight integration with a long-running workflow process. The task UI is relatively simple, so the application developer defers unit testing for the review task until the team integrates it with the long-running workflow process.

Next, the application developer does integration testing.

Integration Testing

Testing for the entire business process includes the following work:

• Publishing and activating the latest versions of the task UIs
• Publishing and activating the latest version of the long-running workflow process
• Compiling the latest UI configuration to the SRF, including business layer configuration modifications

To test the configuration in the development environment, the application developer uses the Siebel Server and the Siebel Web Client because a long-running workflow process cannot run on the Siebel Mobile Web Client. The developer uses the Task Debugger to analyze any defects that exist in the task UI logic.

Next, the application developer performs system testing.

System Testing

If the configuration appears to satisfy the business requirements, then the application developer uses Application Deployment Manager (ADM) to migrate the entire configuration to a test environment. ADM typically includes migration of new or updated LOVs that a task UI uses. The developer verifies functionality, and then tests performance and scalability.