Testers don't and can't prevent bugs : Alltruism or Sense of Pride ?

One of the fashion statement associated with testing these days is "testers should focus on preventing bugs rather than finding them". This is a very tricky idea and is full of traps for testers. Recently a post came up in software testing yahoo group that somehow got into this topic of preventing bugs.

Coming from the context driven school of testing and trained by likes of James Bach, Cem Kaner, Michael Bolton and others - I was skeptical about testers preventing bugs. Fundamental idea of our school of testing has been that as testers we bring to the light the information about bugs and risks in the software we test. Then we report it in a way to stakeholders (powers to be) to act on it.

Many testers fall into trap and take upon themselves (may be due to role/corporate hierarchy pressure) to task of preventing bugs. After all - who does not like someone who prevents bugs than someone who simply reports. Borrowing from manufacturing industry - many business leaders in IT and IT enabled business - firmly believe in prevention is better than cure. Who can resist the nobleness of preventing or saving "nine" by stitching in time.

Let us consider following two cases -

Testers prevent bugs in the requirements by asking question about ambiguity in requirements. Requirement bugs might not be counted as bugs by many - they might be termed as unclear requirements. Calling out what is not clear in requirements is one of valuable contribution of testers.

When Pairing with developers - testers prevent bugs as and when bugs are occur. For example tester may shout .. "hey you are missing exception handling code for that exception or hey you got if loop condition incorrect". That is closest you can get in preventing bugs.

In an email conversation with Michael says -

"we do not use a binary model “pass or fail”.  People who do that are setting themselves up for bad testing.  A product—any product—can “pass” a test but still have terrible problems.  A product can “fail” a test, yet  there’s no problem.  (For instance:  the square root of 2 is 1.4142136, right?  Well, it isn’t; the square root of two is not a rational number; it never ends, and certainly lot at the seventh decimal place.  But for many—even most—circumstances, 1.4142136 is good enough; just fine; not a problem."

This has been a great learning -- testers throw light on ambiguity - that does not mean they prevent bugs happening. Similarly,  in pair testing - testers spot the bug in shortest time possible but they did not present it from happening... that is "early bug detection".

Thanks James and Michael - lesson re-affirmed.

Chief Value Officer vs. Chief Feelings Officer - Perills of Reification !!!

"Yet the danger if reification is all too real. We fall in love with our models, yet we need to be reminded that they are just models of the real world." Lynn Chiu


A good friend of mine Ray Arell in a tweet asks "why not have a CVO - Chief Value Officer". The word "value" always evoked a very strong internal response in me when I saw it being used in a way that Ray used. This word like others in the same league such as "Quality", "Customer Experience" - is notorious or victim of being reified (not rectified). Michael Bolton first introduced me to this word when we were discussing about abstract vs. concrete things. I learned from Michael that reification leads to gross misrepresentation of idea/word and leads to "gamification". It is a thinking fallacy and all intellectuals/thinkers need to be alert about such thing happening.

What is Reification?
In simple terms - reification refers to considering an abstract idea as though it is a concrete, countable, measurable thing. It is about wrongly understanding an idea as a thing. For example counting how many ideas are generated in a brain storming session is an act of reification as idea is not a thing - counting and doing all sorts of maths around it does not make sense. Here we say "idea" is reified as a thing. Other examples include making objects out of subject human experiences like emotions, feelings, values (say family values, social values) etc.

Marxist definition of reification is about "thingification" of social relationships. Among several perspectives and meanings for this term - I would like to use this definition for the purpose of this post - "A fallacy of treating abstraction as though it is a real thing"

Why reification is problematic?
First of all - reification is misinterpretation of reality of nature of what we are dealing with. It's a fallacy, an error in thinking and communicating. Reifying an idea into object is to strip off the subjectivity, mystery and complex richness of the idea. One common outcome of reified communication is both giver and reciever will have two different meanings and interpretation of what is being conveyed.

Consider yet another term "Quality". In software testing world we are all are familiar with this word. There are more than dozens of definitions of this word each fitting to a specific context and it demonstrates how the term quality offers itself to reification. Quality stands a mask for so many desirable attributes of a thing or a service. Instead of adjectives like "fast", robust, flexible, Easy to understand, cheap we can say quality and get away with bothering about all the specificity and correctness of what we want actually. That is power of reification but that is incorrect, manipulative and bad way to communicate.

Similarly with respect to motivation and change management - we often commit reification error. Social constructs such "percentage of work completion" is often regarded as measurements of real objects when it is the best an idea.

In the word of testing - there are famous examples of victims of reification. Requirements, Test cases and bugs. All these are complex ideas being generated as part of our quest to create software from requirements specified in natural language that gets interpreted and implemented into formal computer language. In the word of agile, we have stories that now replace requirements. A development lead announces in the first sprint meeting of a project  "we plan to delivery 18 stories in this sprint".  18 what ? stories. A test lead is asked "how many test cases you team plans to execute in this release"? In another case, during a project postmortem meeting - a comparison is made between number bugs logged in a given release to the number corresponding to previous release to assess the quality of "this" release. 18 stories, 3000 test cases, 270 bugs are examples of how in today's software world we ruthlessly reify abstract ideas and do math with these numbers. The act of reification allows use the numbers that do not have any inherent meaning of their own when context, giver, recipient and time are removed from them. What happens there after is pure game of manipulation.

Reification is thinking error ... it is a fallacy.

Value vs. Feelings 
In today's business world - the word "Value" is more attractive and sexy. We have terms like value stream, value proposition, value added service etc. Behind each of these phrases, hides a very clear objective, object or a concrete thing. It might be some money, timeline commitment, specific characteristic or outcome of a goods or service. It has become fashionable to use the term "value" instead. Why ? Since the meaning of value is subjective and open for interpretation - it allows one to use word value and imply one thing and later for the same value imply something else. In a sense - using value allows one to manipulate the situation to his/her advantage while not being wrong or incorrect about what is being conveyed through this loaded word "value".

In order to understand the full and correct meaning of word value - we require the context and who are we addressing to. By reifying the word value - we strip off that that richness, context and complexity. Then we start using the phrase to indicate multiple, sometimes disconnected and contradicting ideas as we have left behind context and recipient(s).


Instead of having a Chief Value officer, let us have a Chief Feelings Officer who can understand and deal with customer feelings and emotions about a goods or service delivery. Having this role, corporates can truly claim that they care about individual views and feelings about customers than a rolled, convoluted, metricized - measure such as customer experience.

Many still think that giving good customer experience is having a great looking GUI and exciting animation. Real customer experience, in my opinion is about caring for individual experience in their bare essential with all richness of emotion and context.

CFO - Chief Feelings Officer. Anyone ?