TestingMisconfused

Modelling the Workflow in SQL

The AUT is a series of web pages that provide a front-end to a database, allowing the end-user to view and amend data. The business logic is reflected in a linear flow through the site depending on the choices the user makes.

This allows us to treat the AUT as a series of workflows containing stages, each of which has associated content and possible actions.

Modelling this in SQL gives us:

The WorkflowStage and StageStep intermediate tables allow us to model many-to-many relationships between Workflows and Stages and between Stages and Steps without duplication.

Content and Action Handlers

These are the common routines outlined in the WebAii introduction.

Data Driver

To test each Workflow, we run through each record in the Workflow table and run each Stage identified in the WorkflowStage table. Each stage uses a sequence of steps referenced in the StageStep table. A step can either be checking text content or performing an action (click button, enter data into text field, etc.). The first 3 Controlxxx columns in the Step table allow us to locate a control on screen, the ControlValue is what should be read or written from/to the field and the Write column tells us whether this step is a read or write.

It could be quite tricky to get these intermediate tables correct, so it is a good idea to build a "FullWorkflows" View in SQL to show the fully expanded workflows:

SELECT dbo.Workflow.Description, dbo.Stage.Description AS SD, 
    dbo.Step.Write, dbo.Step.ControlFrame, dbo.Step.ControlType, 
    dbo.Step.ControlID, dbo.Step.ControlValue 
FROM 
    dbo.Workflow 
INNER JOIN 
    dbo.WorkflowStage ON dbo.Workflow.ID = dbo.WorkflowStage.Workflow 
INNER JOIN 
    dbo.Stage ON dbo.WorkflowStage.Stage = dbo.Stage.ID 
INNER JOIN 
    dbo.StageStep ON dbo.Stage.ID = dbo.StageStep.Stage 
INNER JOIN 
    dbo.Step ON dbo.StageStep.Step = dbo.Step.ID 
ORDER BY 
    dbo.WorkflowStage.ID, dbo.StageStep.ID;    

Then, back in VisualStudio, we need a method to walk through these expanded workflows:

DataTable stepT = SQLexecuteQuery("FullWorkflows");
foreach (DataRow stepR in stepT.Rows)
{
    if ("True" == stepR["Write"].ToString())
    {//perform actions
        ePA_Perform_Action(stepR["ControlFrame"].ToString(),
                           stepR["ControlType"].ToString(),
                           stepR["ControlID"].ToString(),
                           stepR["ControlValue"].ToString());
    }
    else
    {//check content
        ePA_Verify_TextInFrame(stepR["ControlFrame"].ToString(), 
            stepR["ControlValue"].ToString());
    }
}

You can filter which workflows are run by amending the query to something like:

DataTable stepT =
    SQLexecuteQuery("SELECT * FROM FullWorkflows" +
                    "WHERE (Description LIKE 'Update Investment Decisions - Switch Funds')");

Note that there is no business logic in this script – the logic is modelled in the sequence of Workflows, Stages and Steps.

From webtest to a Workflow Driven Test Framework

When I started out devising a test framework for this hateful OAS application. I really had no idea how I was going to cope with its eccentricities. TestComplete had been my web testing weapon of choice for the last 7 years but this beast had it completely bamboozled. Visual Studio gave me some hope, in that I could record and code a webtest without BSODding my PC, but I ended up with ridiculously long and - let's be honest - completely impenetrable scripts.

Now, with less than 200 lines of very readable script - which won't necessarily need updating when I want to change the tests - and 4 (or 3!) small SQL tables, I can test any workflow in the application. It's not the fastest running test in the world - but that may be down to me not being very selective when I refresh the DOM. One other great advantage Visual Studio with WebAii has over TestComplete is that it doesn't seem to get confused about whether the page is ready or not - and I don't get the IE freezes and white-outs that have plagued my testing up to now.

It's been a long and fascinating journey and as much as I begrudged having to test this application in the beginning, I am now happy that I have a working, flexible solution that I can apply to all our websites for a long time to come (weeks at least).

The bad news is that I've had a quick look at Visual Studio 2010 Beta 2, which comes with its own UI testing framework and the test replays run like a stabbed rat, so all this work may be short lived...