When a fellow tester or colleague or stakeholder ask, "Let us find the bugs by testing" and "Let us learn the problems and risks by testing", I think the below.
Why testing is often seen or taken granted just to see the bugs out there or the risks residing within, if at all? Do programming is to introduce the bugs and fix them, all in all? Then why testing and testers are seen as behind the bug always or put around the bugs?
I see this attitude (mindset) and expression of looking and practicing the Software Testing, yielding to experience just the one small part of a petal of the craft. While there are other petals and benefits of the craft, it goes unused and unexplored. Unlocking from this expression and attitude becomes so complicated, it looks inseparable from the above said thought. The reality is, it is distinct and separate; but, taken as one.
While programming is to solve the problem, isn't the testing is to learn the problem if any in hand. Before this, I ask myself, why there should be a problem always to solve? I see this notion i.e. seeing a problem in first hand, makes the mindset just to focus on the problems rather than placing the problem as one part of the study. That means, problems get associated with everything, then! Why so? We look for it placing the importance for it? Does that importance is studied well to make it important to emerge as a whole than being a part?
To recollect the definition what I remember from Dr. Cem Kaner is, Software Testing is an empirical technical investigation activity conducted to provide (learn) quality related information of product to the stakeholder so that they make informed decision.
Here he does not say about the 'bug' or 'problem' or 'risk' or 'defect'. I see this is so close to daily work I do in my practice. After this I get the question for myself, "He says, 'information' about quality criteria. Is there anything that is 'not a quality criteria' and still the tester provide the information from her or his testing about that too?"
Leading from here, my thought spans to a branch. This branch gives the thought of the word 'value'. In programming, declaring a variable and assigning it a value is simple? And this assignment takes it's types and namespace in the defined environment. If this is simple to declare and assign a value, why this value of a product tend to become so complicated when it is tried to in terms of a software product to use?
Now should I learn the value of each and every aspect that is getting collected, then written as part programming and coming out as a usable commodity and the outcome of using it? Is that value here is -- a bug or problem or risk, I learn from my testing?
Later this points me to line -- "A bug is that which threatens the value of a product". If this is so evident, then, why I hear or asked to look for bugs alone around the product? And, not to learn the value and what is that trying to diminish it in the context?
This further makes me to ask myself, fundamentally, are there anything else in the existence, which is non-bug that can threaten the value of a product and annoy the user? Something as this, programming is just to write buggy code? If so, testing is to look and anticipate just the bugs?
Unfortunately this has crawled so deep in the industry, we want bugs but not the testing. We ask the bugs and not the testing. The impact of this is recursive and passes on to the generation of testers as it is come to my time as well. It makes me to look for bugs (information) i.e. one of the outcome from testing while ignoring and tending to being away from the testing.
I'm not saying to unroot this or to do anything that helps. But, is it possible to give a thought from the practicing tester before asking anyone to give the thought about this. I want to give my thought about this each time I test to learn what I'm doing and practicing.
