I work as a software developer. A developer who doesn’t really like testing so much - so many more interesting problems to solve, so much more functionality to improve, why spend time writing tests?

“Wait a minute there”, you will say, “haven’t you created a testing tool? Don’t you spend most of your time talking about testing, how to test stuff etc.?”.Well, yes and no.

I am an engineer. Trained as an engineer, I think like one: Take a problem, define it’s parameters, devise a solution, identify edge cases, make sure the solution stays within the parameters.

The creative “destruction” really good testers bring to the game eludes me, because I think in solutions and that narrows my scope. But as a software engineer I also think about what will happen if something changes. Trying to foresee change is a sure way to bloated software and unmanageable featuritis ending with a (s)crap heap.

So in my engineer’s mind tests serve to identify breaking changes as well as proof of a working solution, building insurance for the future. This is a limited view of testing, as it concentrates on the normal flow and the few variations and error cases identified during the design.

You could say that as a software engineer I am interested in tests for their initial validation of the logic and their usefulness in detecting regressions.

What I can say is that I am not really interested in actually running tests. From the engineering point of view, this is a job for the computer, a very interesting “problem” to solve, hence rutema, a tool for automating test execution.

Devising tests, now that is a whole craft, a way of thinking, requiring skill, intelligence and quite a bit of discipline. Just like what is needed to write software anyway, isn’t it?

Good testers approach the solution as a problem, deconstruct it and find the holes. Discipline is essential - wildly clicking on a GUI might net you a few errors, but if you cannot reconstruct them there is no test and no value.

Good judgement, imagination and discipline are not automate-able. You need a tester, a good tester, first. And you need him/her in the team, in regular contact with the developers, exchanging ideas, pointing out design flaws, helping shape your software.

Automation is necessary whenever there is repetition. Originality is required before it, and that you can only get from a good tester.

This entry fits with the - old now - entries detailing the ideas behind rutema, starting with “On test automation and management, part I”.