I include a part of this essay on Test Methodology as it gives some insight into the way I approach problems.

This was not a commissioned report. I was doing work with the Testing Department of a large academic institution who were using a Peoplesoft data system to handle much of their administration. The essay was a summary of my own thoughts on how testing, which has only recently come into the mainstream of data management skills, might best develop.

This institution had at the time a larger test department than most, as it was common then, and still is, to split software testing between the developers themselves and the end users, and so to forgo the need for a specialised test department altogether. This has led to a lack of formalisation about testing beyond the rather vague and coverall terms like Agile, Waterfall, Scrum, Unit and Regression Testing and the like. Indeed, the whole field tends to be rather blanketed in vagueness, with test procedures sketched out in each test writer’s own style and preconceptions, generally set out in spreadsheets, which are of course wonderful things for permitting looseness of expression.

My central thesis was that test procedures can be precisely defined in an algorithmic way using only slightly modified standard object-oriented programming languages, and that this would make them completely rigorous and unambiguous. This would also open the way to more automation, although I did warn against pushing this too far: a human tester will often see errors a machine won’t.

The essay started with a review of a program (again US spelling for the things that run on computers) I’d written to convert test scripts written in a somewhat haphazard way in spreadsheets into a first level of standardisation that enabled them to go into a database. This (wholly successful) project showed that the apparent wide differences in test scripts were largely imaginary, and the individual steps could in fact be described in a consistent way quite easily.

From there I developed in some detail a language specification for a proposed test scripting language that could become standard.

A particularly tricky area was test data. These tend to be specified very loosely indeed, worse even than the actual test procedures themsleves, and so required some thought. This is the chapter I include HERE.

I’ve expunged all references to the specific application I was working in, except that it was based on Peoplesoft’s Campus software, now maintained and distributed by Oracle. So what you see is just an essay on Test Methods in general and that’s what I’ve called it.