managing test flow

Working with the framework, as in actually using it, is fine.

It's pretty much bullet-proof and idiot-proof. It has to be. It's all keyword and data driven by user-populated input on Excel sheets .... and no use if it crashes halfway through a run (which can be several hours and run unattended overnight or in an empty test lab).

I wrote it myself, from scratch, as script extensions. These are stored in their own project in our version control system so can be applied to new installs of TestExecute or whatever. As you say, the framework itself is fiarly complex (although not hugely so). I've developed several frameworks before in previous jobs so I have a pretty good idea these days what I want from one, how I want it to work, what I want it to do, etc etc.

Anyone can update it of course, but it tends to be me as it's "my baby" so to speak.

I always write my own as I always, at some point, hit a point with built in flows and controls that I can't quite get it to do what I want. The DDT offering from TestComplete is a perfect example. It's good, but not quite as flexible as my own Excel handler. Plus, if I get asked for a specific modification to the way things are handled, I can easily modify and update things myself.

The framework itself seldom needs maintenance. (It's completely project/application agnostic - as a framework should be!) I tend to to the additions and updates, but as I say, any half decent dev would also be able to do so.

We only have one dev license for TC. So I do tend to develop all the actual test functions (which are project suites completely separate to the framework). But it's the manual testers who then use these (and the framework) to actually build and run tests.

My framework handles:

• Test control and flow (including the above mentioned markers and dependencies)
• Logging
• Results (dropped to a shared folder and also e-mailed to recipients of your choosing) - both for individual suites and full summary
• DB backups & restores (at user request)
• Service and process checks, stops and starts (at user request)
• Test updates to TFS via it's API (so automated runs can update test suites in TFS)
• All error handling - although recovery is usually handed back to the project suite as this tends to be application specific