Today, finally, the oddness of two words dawned on me. The words are ‘software tester’ and I used them, in a conversation, to describe my role in the project I am currently involved in.
The first reason why I felt strangely alienated from the description ‘software tester’ was that, for last couple of months, I have not tested software. Not a single piece of software has been been submitted to me with the question “Can you please test this?”. Instead, I’ve been reviewing (mostly functional) design. All I’ve seen is complex thoughts spelled out in writing.
Reviewing – from a testing perspective – is hard work. I have sat down with other reviewers and no one of these persons ever described reviewing as even relatively easy. It can be tedious and mind boggling at the same time. It involves reasoning from many perspectives. It involves recognizing the traps of your own reasoning and that of others. And it takes a lot of effort to find out which set of perspectives will lead to a manageable conclusion.
This brings me to the second word, which is ‘tester’. Today, through a couple of discussions, I realized that the tester – the independent assessor of quality – is as much bound to the context, as much the modifier of context as he is the assessor of the design. Though we would like to see ourselves as the evaluating party, it is this evaluation, this test, that is part of the design, part of the meaning of a system in its context. It reminded me that the design is bound to the tester just as it is bound to the designer. That means that we should be excruciatingly careful in selecting our approach to testing and that we should be looking at not only the result of the test but at the effect of the test on the design. The latter may turn out to be a much bigger issue than the former. Which is why I think ‘ tester’ is just a very odd word.