How do you structure workflow tests

I like to use a data/table driven model where the driver of what tests to run, the contents of the tests (individual steps and parameters), and the order in which they are executed are stored externally from the automation code itself.  I like to use CSV files for that data because they are portable and easily editable by any user with any variety of tool.

The script code consists of "atomic" steps, each one a class in Javascript which has properties corresponding to the data needed to execute the step and a method for the actual execution.  A test case is then constructed in code from the CSV data to be an array of instances of the steps.  A test case is executed then simply by traversing the array and executing the objects' primary methods in the designated order.  Rather than using Test Items to build the report and execution, there's a minimal number of test items:

1) Reads the data and builds the test cases from the CSV files

2) Traverses the arrays and executes the tests

3) Cleans up the automation and any finalization routines.

Reporting is built from log entries using AppendFolder/PopFolder etc., to build a report based upon log rather than on the built in TestComplete reports.  Others have adapted this to also write out reports to CSV, XML, or other formats internally.

The pro that I've found for this method is that you can have a few people whose job it is to maintain the highly object oriented, modularized code.  If the test case requires a minor change in work flow, rather than needing to redo a whole test case, you only need to modify code for the individual step/class.  The more "atomic" the steps, the easier it is to maintain.  Additionally, with sufficient documentation, ANYONE can build a set of test cases for execution without having to know anything about TestComplete or the code involved.  They just populate a set of CSV data files and click a desktop icon to run the tests in TestExecute.