Who defines Testing?
I just read a post by Tony Bruce on making excuses for why a bug was not found until later testing cycles/UAT/Production. Good post, great read, as always. You can find it at dancedwiththetester.blogspot.co.uk
In the last part of the post Tony writes:
I am not a gate keeper, I am an information provider, I have limited time to provide what information I can. I will do my best, the people around me will do their best and sometimes we will not be able to investigate everything.
This reminded me of a matter that has been bugging me a bit for a while; I see a lot of people stating that “Testing is…” and then some definition or list of tasks as if this is the One and Only Truth.
Oh yeah? Is it really? According to whom? Who decides?
First, just to be clear, I agree with the idea that testing is, or at least should be, about uncovering information and assisting the rest of the project in making quality related decisions. Testers are people too, with brains, and having them mindlessly following scripted checks that hopefully will not fail, and thus not uncover any new information, is downright cruel (yeah yeah yeah, there are always exceptions).
James Bach says that testing is “Questioning a product in order to evaluate it.”
Jerry Weinberg says that testing is “gathering information with the intention of informing a decision.”
Cem Kaner says that testing is (deep breath, now) “A technical, empirical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.”
I [Michael Bolton] say that “testing is the investigation of systems composed of people, computer programs, and related products and services.” What’s more, I agree with the three above, since, broadly speaking, we all mean more or less the same thing.
I have not personally sat down developed my own tailored definition. At the moment I am content with saying that these definitions presents a world of testing where I want to work. It makes sense to me that people would want this job to be done on a project, and it is an opportunity for the person doing the job to learn all sorts of wonderful things.
While I have a fair idea about what I want testing to be, or what I mean when I talk about testing, I find it quite clear that not everybody shares that idea.
Regardless of where in the continuum between fully scripted or pure exploration the applied test approach is , people seem to have very different ideas about what the purpose of testing is or should be. Some people is adamant about testing being performing some precisely described operation, and then comparing the output, or at least the part of the output they thought about when describing the test, to an expected result. In some cases it seems that the most important objective for the “testers” is to produce a specific amount of paperwork, regardless of what it actually contains, so that everything is according to The Process (regardless of whether that descriptive document actually fits the project and the context at all). In this world of boiler plate text and ill-fitting templates, ticking of the check boxes is what counts as getting things done, and how its is done is of less interest. Some times there is the added desire to Verify the Requirements, because we all know how that “Assures Quality”. I have seen variations all over the spectrum. From what I just described, all the way to testers and developers pairing up, focusing on uncovering the mysteries of the product together and prioritizing shipping great stuff over obsessing over “expected results”.
My point is, before this get way too long… people have different ideas and expectations.
You might not agree with them, and you might very well try to explain your view, hoping to persuade somebody, or maybe to be enlightened yourself, but in the end… is it not whoever pays for your services who decide what testing IS… in that given context?