Test case management

Product life cycles are becoming shorter due to customers' demand for new features combined with the growth in the availability of RAD tools. The effect of this on testers is to create more work. Some projects produce little controlled documentation and, as such, test case identification requires pro-active effort from test planners.

In addition, business managers want to see the test phase of a project shorten in the same order as the development time. The conditions under which we have to work are changing, so the way that we plan and execute testing needs to change accordingly.

When it came looking for ways of streamlining testing it didn't take long to identify test case research and documentation as the most resource intensive sections of the test cycle.

Our original test case scripting process involved one test case per A4 sheet of paper; each sheet was a self-contained unit with details of why the text exists, how to run it and what was expected to happen.

This caused a number of problems such as not being able to organise scripts into meaningful cycles and difficulty in the ongoing maintenance of scripts - test cases were not easily linked with others and there was no indication of the test's level of abstraction. When you add these issues to the general difficulty in identifying test cases in the first place, it provides good reason to redesign the approach.

The procedure now in place addresses many of the problems inherent in the old system. The new process is driven by business cases. Each business case is a high level test and is documented in a format that more detailed tests inherit.

The document template uses MS Word tables, which makes it easy to manage while retaining professional appearance. Building a script of test cases based on business requirements allows the rapid production of a draft document which gives good coverage but is obviously short on depth. If necessary the script can be used at this point to drive testing where deadlines forbid more detailed planning.

The draft business case scripts is used as a backbone onto which tests of varying levels of abstraction can be hung depending on the depth of testing required. Identifying the high level test requirements as a first step makes it difficult to miss important areas of the product under test at a later stage when the planner's mind is on more detailed matters.

The format of the document uses a hierarchical numbering system to link detailed test cases to the originating business case. This approach also allows groups of business cases to be collated into test cycles for easy management. The levels of abstraction can be varied on a cycle or business case basis, depending on factors such as risk, without impacting the flow of the document or the tests eventually driven by it.

The format of the document makes life much easier when it comes to revising it for new releases. Its structure of: Module/Cycle; Business Case; Abstraction Level 1; Abstraction Level 2; and so forth, allows the test planner to rapidly identify and target those areas requiring modification.

This combined with the feedback from the previous execution of the document (derived from the test execution log), allows the production of tests which are highly relevant and straightforward to run.

Few problems have been encountered to date. There are, of course, areas of complexity which require deviation from the overall approach built into the procedure but such cases are easily handled by including details of the change in the test documentation.

Pepe Tozzo, Test Manager, ICV Ltd – Datastream/ICV