Udostępnij za pośrednictwem

Putting the Context back in Context-driven testing

  • Artykuł

Tonight I was having dinner at the superb Italian restaurant L'Olivo along the canal in Nyhaven, Denmark with my 5 year old daughter. She was slightly upset because they didn't have chocolate mousse on the dessert menu so when the waiter came by to take our order she neglected to say 'please.' I reminded her that we should always say 'please' and 'thank you.' She asked, "Daddy, why do we need to say please and thank you?" I told her that is was the polite thing to do, and that whenever she asks someone for something she should say 'please', and when someone presents her with something she should say 'thank you' or 'no thank you' if she doesn't want it. She paused for a moment, then said "But, if it is an emergency then I don't have to say 'please'...right?" Amazing! Not only does she understand the context in which it is polite to say please and thank you (and she usually is polite) she also understands and was able to clearly articulate one specific situation that it is not necessary to say that because of a different context. I, of course, had to agree with her that in that context she did not have to say please or thank you.

Unfortunately, not all conversations with some people go as well from my perspective. For example I had the following discussion recently with a reader from a self-proclaimed member of the so-called context-driven school of testing:

[Reader] "We never know what will happen if we do "X" with the software and can never be sure about all possible outcomes."

[Bj] "In your example above "We never know what will happen if we do "X" with the software..." is true. Of course we won't. Because there is NO CONTEXT!"

[Reader] "Because there are so many contexts possible, hence the answer would depend upon who is asking and in what context. Context driven software testers are aware of this and constantly practice probing around context."

[Bj] "Since you made the statement "We never know what will happen if we do "X" with the software...", I am asking for you to define the context of "X" and the software."

Unfortunately, this is where the conversation ended. So, without providing a context (or when taking words out of context) then I agree there are "so many contexts possible" and there are also contexts that are completely impossible or improbable. I have nothing personally against people who wish to label themselves, or identify themselves with a group "whose thought, work, or style demonstrates a common origin or influence or unifying belief." I personally don't believe in the so-called schools of testing, and previously explained my positions in the following posts, End the segregation of the four schools of testing, and Schools of Testing Revisited. I think software testing is difficult and challenging and one must constantly view the problem from multiple perspectives within the set ( all realistic possibilities ) of circumstances or facts that surround a particular event or situation.

For example, I know that a 0x5C character code point (the backslash) on a Windows operating system is a reserved character code point and cannot be used as a character in a file name. In a completely different context such as using a 0x5C character code point in a UNC path then that character code point is a valid character but only within specific limitations. So, I won't waste my time or my employers time with wild speculation and "practice probing around" searching for bizarre unrelated contexts. For example, I won't attempt to see if the 0x5C character code point can be used in the 5th and 19th character positions of a file name on a Texas Instruments 99-4A computer, or design a test to check whether it can be used as part of a file name if I set the computer internal clock to December 13, 1901. I could try these things (assuming I could find a working TI 99-4A) but, these are random and meaningless contexts.

At a recent conference a speaker asked "what is an integer?" I thought...hmm...an integer is a positive or negative whole number or zero. Then the speaker said, an integer is different depending on whether we are talking about the C# programming language, the Ruby scripting language, or an embedded device. Then I thought...well, an integer is still a postive or negative whole number or zero, but given more specific context I suspect the speaker was referring to data types in programming languages for the C# and Ruby example. In the C# programming language an integer is an intrinsic data type. In Ruby it is a class, and on an embedded device...well it is a positive or negative whole number or zero. (I must admit, the embedded device threw me for a moment because including embedded devices in a comparison set of programming languages seemed analogous to comparing a rhinoceros to apples and oranges (the only similarity is that they all have skin). So, in this particular situation in which we are given a more specific context to clarify the key word 'integer' based on "the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect" we know that the speaker is referring to integers as data types on a programming language, a class object on a scripting language, and well...an integer on an embedded device.

Context denotes "the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect" or "the set of circumstances or facts that surround a particular event, situation". This is important because the English language is composed of words that have various definitions depending on how the word is used in a written or spoken statement. Unfortunately, when I have discussions with people who identify themselves with a singular way of thinking they often take one of the key words from the statement,  apply an alternate definition of the key word or element of speech, and then attempt to rephrase my original statement resulting in a tangential interpretation of the original statement or discussion because it is completely out of context!

For example, someone suggested in an article that the phrase 'best-practice' is an idiom (an expression whose meaning is not predictable from the usual meanings of its constituent elements, as kick the bucket or hang one's head, or from the general grammatical rules of a language, as the table round for the round table, and that is not a constituent of a larger expression of like characteristics). I challenged their use of the word idiom to describe the phrase "best practice" and suggested that it is actually an adjectival phrase. They replied that an adjectival phrase can be an idiom and and idiom can be an adjectival phrase. Yes, that is true when there is no context! For example, let's take the phrase "lame duck." In one context it is an adjectival phrase that may refer to a duck with a broken leg. In a completely different context the idiom "lame duck" refers to someone who is incompetent. I happen to think a "best practice" is an adjectival phrase that describes a practice which is better than similar comparable practices in a specific situation; I am still waiting for the commonly understood idiomatic inference of "best practice."

Dissecting every word in every statement for the sake of questioning the various connotation of words, or attempting to rephrase sentences based on limited knowledge of the domain space in which words are used in specific contexts (which I perceive is what is meant by "who is asking"), or thinking tangentially by removing or applying unrelated contexts is simply playing with words, and fun for debate from a philosophical perspective. Philosophy involves a rational investigation of 'things', and is extremely useful in that it helps us think of 'things' from various perspectives. However, the statement "...there are so many context possible (for what will happen if we do "x" with the software), hence the answer would depend on who is asking and in what context" is completely irrational because the person has removed the context from their own statement. Thus, it is impossible to perform any rational investigation of "x" because the speaker is unable to provide context for "x" or for the software which they are applying "x." Philosophy is really about asking questions; but philosophical discussion rarely provides any facts or empirical evidence that decision makers rely on to make critical business decisions.

But, as a professional tester I need to put things in realistic and meaningful contexts which are appropriate for the task. I also need to think of other possible rational contexts that I can clearly articulate. I need to not only investigate software and the capabilities, attributes, and limitations of that software from various rational perspectives, I also need to provide my managers with valuable and substantiated information which they can use to analyze risk and make better qualified business decisions.

I happen to think we have always viewed software testing in various appropriate contexts (hence context-driven is nothing new or revolutionary). So, instead of playing with words and offering alternate and unrelated contexts of a sentence element or situation, I think we need to drive the context of context-driven to mean focusing on the appropriate context for the specific situation which is being discussed, reaching a common understanding of the jargon commonly used by professionals in a common trade for clarity of understanding (as opposed to simply making up new words to sell our services), and we need to stop rephrasing or perverting someone elses words to suggest some irrational or metaphysical explaination of how things might be in an alternate universe.

And, by the way, my daughter settled on the profiteroles for dessert which she loved, and so she graciously thanked the waiter not only for the wonderful meal, but also for the excellent dessert suggestion!

Comments