Inside Out of Test Design: When each disguises each other - Test, Design, and Techniques -- Part 1

I have been and continuing to be mesmerized about the Design Patterns in programming space. While I'm continuing to look at the Design Pattern, I ask myself is there anything similar in the 'software testing' space? If software programming and software testing are subset of a super set, the engineering, then design pattern and test design are to each other. That is, the both exist to support each other well enough in the context. Isn't it?  This is the question among lot other which runs in me when I think about Test Design.

Further, I go into my thoughts (of today) for letting know myself what I understand for 'test', 'design' and 'techniques', I hear below from me.

• test -- An experiment which is an open ended and whose outcome is unknown.
• design --  The set of ideas which says how to (I) use it or how to go about; and how I see it further to use it by learning. How simple it is to use for me, those are the attributes of design with the learnability in context being prominent.  In other ways, it comprises of pattern as soon as I say, 'design'.  Each design has a pattern isn't it?
• technique --  applying; i.e. a skill being applied to study, observe and evaluate a subject of interest further.

While I'm learning this, do I see a familiarity or the familiarities in these three above said?  May be this familiarity or these familiarities, it disguises each other while they are distinct and co-exist mutually in practicality of Software Testing practice.

Why one cannot see the differences or draw the differences between these other is, a simple fact. Yes, the fact, which is not studied quite often; hence it is a fact.  The unquestioned fact is, all three of these are heuristics - which helps in discovering, learning and solving, while it can fail as well.

A test does not help one to learn, discover and solve? But how a test can fail? Test never fails, it provides the information and I tag the label of true positive or false positive to the outcome of it. Likewise, is the design and technique, it helps in discovering, learning and solving; and as well it can fail too. But how do I see the 'fail' in case of design and technique is -- it did not meet the purpose or serve the purpose. Because out of the design and technique, I expect the discrete value which is of usabale, reusable and valuable. Whereas for a test, I see the information is an outcome from the execution of it (or out of not execution as well; not testing is as well a useful test in a context).  This is where the disguising appears by each others to each other.

Do I want "the bug" or "the testing" ?

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.