*** Column published in Capgemini's COP IT Testing Newsletter ***
As I’m writing this column the snow that has been ‘harassing’ me the last couple of weeks is retreating slowly from the garden and the streets. You should think that would make me some kind of happy, but that isn’t the case, not entirely. It isn’t that the snow is finally going away, that’s the part that’s OK. But it is the way it’s going. It should have been a temperature rise and a bit of sun perhaps that would initiate ‘the melt’, but in this case it’s rain that causes it to disappear. And I guess I like rain even less, in combination with melting snow that is.
In a time that a lot of people have made resolutions for the new year and are spreading ‘best wishes’ it started me thinking. What if some of it came true, but the way you intended it to come true wasn’t exactly what you had in mind.
For example; you have a resolution that says ‘this year I’ll quit smoking’, a very common resolution as I may add and normally a very healthy one. I guess everybody agrees with this resolution, because most people have the frame of reference that the way this is done is by a live person not lighting a cigarette anymore. But it’s another story when one ‘quits’ smoking because they die. I’m certain that nobody had dying in mind when setting this resolution.
The key point here is -I think- the accuracy and completeness that has not been made. And then it occurred to me that ‘requirements’ for software- and systems are set in the same way and that in some cases when we get to testing these requirements are implemented exactly as they are described, but the client isn’t happy at all with the solution. A lot of times this causes incomprehension and even arguments. I think that it is important to remember in these cases that maybe the requirement itself isn’t the most important part, but the way that the solution to this requirement is implemented is.
I know it isn’t the job of a tester to set up the requirements, but as tester we do have a lot to do with them, and in my personal experience I do have the occasional argument with a client that the solution to the requirement is exactly implemented as described but the client persists in not being satisfied with the solution.
I think the requirement specifier should be very specific by adding the way a solution is – process wise- implemented and as a tester we should be extra aware that when testing solutions the description of the corresponding requirement is in such a way documented that it is clear what the solution should exactly be, including the expectations of the client. Having said this, I think we can deliver a more satisfying product to our customer when applying this knowledge.
With regards to 2010 intentions and best wishes I would like to conclude with a very known saying: Be careful what you wish for, it might come true!
