Usage of words

I came across the following tweet:

Testing vs. checking is a low value semantic argument used by a cult for proving worthiness in the cult. All it ever was or will be.

— Marlena Compton (@marlenac) May 18, 2017

I tried to reply on Twitter but the message I tried to portray did not come across in the way I wanted it to.

Disclaimer:  I am not, nor ever have been a member of any cult.

Marlenas' words came across very strongly and appear to be based upon their negative experience when encountering discussions on the use of these words.  Others stepped in with their own experiences and the main message seems to be that the use of these words have been to derailed important discussions.  I find that a shame, since to me the distinction with these words has been useful to help talk to executives and others from outside the testing world about the risks of unfocused automation and testing.

My concern in the statement by Marlena is that the distinction is of low value  and a semantic argument.   Semantics and the meaning of words is vital for society to be able to flourish and this has been going on for a long time.  People have argued over what certain words mean and over time the meaning of some words change.  Some are taken over to deride or insult people and sometimes these words are reclaimed by those who are being insulted.  For example the word "Queer" to some this is a hostile word to others it is a badge of honor.

I worked in Israel for awhile and often would get strange looks when running workshops and replying to a question I would say 'smallish' It was awhile before I figured out that 'ish; is Hebrew for 'man' and I was saying 'small man'.  Culturally words can have different meaning and cause confusion, the same can be said of the words'checking 'and 'testing'  Using these words in the right situation and context to inform and have a discussion can be useful however if used to make a point or win an argument it becomes less useful.  If used in an attempt to show superior intellect then the discussion is already lost.

I use the distinction between the words when discussing the testing effort.  How much checking has been done against the amount of testing that has been done.  How much effort have we spent on putting in place explicit knowledge, information we feel we know, against the effort on information that we do not know, tacit.  Knowing the difference between these two items can be vital to help mitigate risk.  If all the effort and money is being spent on checking with very little testing then there could be a risk that something we do not know could be dangerous.  Unless we spend a little more effort on testing to uncover more of what we do not already know then there is unknown risks.  Another example could be that the product is mature and changes are minor so more effort is put into the checking.

For me having these meanings helps to inform and tell a story.  I do not use them to score points or be a member of a cult I use them because they have a value to me in my context.  I do not really care if you use these words or not.  I have explained how I use them and the usefulness I find in them.  Yes I will discuss with people why I feel the distinction has value but at the same time I respect others opinions and viewpoints.  To me it is a useful tool to be able to communicate with teams around the world.

MEWT4 Post #2 - A coaching model for model recognition - Ash Winter

Abstract:

As part of my role, I often coach testers through the early part of their career. In this context I have noted a pattern in the application and interpretation of models. They are generated internally through various stimuli (learning, influence of others, organizational culture) and then applied subconsciously for the most part, until there is sufficient external scrutiny to recognize them. To this end, I have created a model of questions to help testers to elevate their internal models to a conscious level and begin to articulate them.

To this end I hope to articulate at MEWT:

• Presentation of the model of questions to determine internal models in use, without introducing models explicitly.
• Use of Blooms Taxonomy to visualize a coachees modelling paradigm and the steps towards modelling consciously.
• Practical examples of using this model to assist early career consulting testers to cope with new client information saturation.

Slides for the talk by Ash can be download here - https://mewtblog.files.wordpress.com/2015/10/coaching-model-for-unrecognised-internal-models.pptx

____________________

The first speaker at Mewt was Ash Winter who talked about his experience of coaching and how coaches have their own internal models which still could be wrong.  Ash talked about the issue he and other coaches have experienced with using models and the risk that they can limit your thinking.  He had noticed that some coaches talk about models without really recognizing that they are using a particular model.  This appears to be especially true in the testing domain.

Ash presented a different coaching model based on Blooms taxonom  to provide a framework of asking questions of those you are coaching rather than providing answers.  Ash stated that we should, as coaches, “Build your model on pillars of questions, not answers.  You are coaching”

The levels of Blooms taxonomy can be seen here:

An in-depth look at Blooms taxonomy can be found here.

Ash displayed a different variant of this during his talk:

Ash stated that he felt that Blooms was good for learning and it was useful for coaching as well.  Since Blooms works on the basis that you work towards goals this also then applies to those who coach and utilize coaching models.   

Ash also stated that his model for coaches is for those who are experienced as coaches and who are involved in coaching those who are early in their career as a tester.  As with any other model Ash did point out that he felt this was a new coaching model which was still evolving and emergent and wanted input for the wider community?

During the discussion after Ash has spoken I highlighted that the Blooms taxonomy approach does have some flaws especially in a digital driven learning environment in which we are now situated. 

The hierarchical approach of Blooms does not encourage deep and meaningful learning aided by digital media.

The problem with taxonomies is their attempt to pin down the complexity of cognition in a list of simple categories. In practice, learning doesn’t fall into these neat divisions. It’s a much more complex and messier set of cognitive processes.http://donaldclarkplanb.blogspot.com/2006/09/bloom-goes-boom.html

Issues with Bloom taxonomy further reading:

• https://eppicinc.files.wordpress.com/2011/08/sugrue_bloom_critique_perfxprs.pdf
• http://www.corwin.com/upm-data/13602_Chapter_1_Marzano_Final_Pdf_2.pdf
•  http://www.learningspy.co.uk/myths/challenging-blooms-taxonomy/

There are alternative learning models which appear to overcome these flaws in Blooms and maybe mixing them together will provide a more robust model for Ash to work with.

For example:

“Heutagogy is the study of self-determined learning … It is also an attempt to challenge some ideas about teaching and learning that still prevail in teacher centred learning and the need for, as Bill Ford (1997) eloquently puts it ‘knowledge sharing’ rather than ‘knowledge hoarding’. In this respect heutagogy looks to the future in which knowing how to learn will be a fundamental skill given the pace of innovation and the changing structure of communities and workplaces.” https://heutagogycop.wordpress.com/history-of-heutagogy/

Or

“Connectivism is driven by the understanding that decisions are based on rapidly altering foundations. New information is continually being acquired. The ability to draw distinctions between important and unimportant information is vital. The ability to recognize when new information alters the landscape based on decisions made yesterday is also critical.” http://www.itdl.org/journal/jan_05/article01.htm

At the end of the talk by Ash the group felt they needed to go away and think more about the ideas Ash has discussed.

To finish I will leave you with a quote from Ash during the talk:

A lot of people do not know what models are sometimes they emerge during applied practice

A discussion on do testers really need to code.

Recently there have been a few posts talking about testers learning to code.

• Rob Lambert: - Why Testers Really Should learn to Code
• Fiona Charles - Why I believe its good for testers to learn to code
• Anand Ramdeo - Do Software Testers need to learn coding
• Maaret Pyhäjärvi  - Learning to Code - Just Learning

I find these discussions interesting and at the same time very worrying.  I have seen many posts that say testers ‘should’ or ‘need’ to code as shown from some of the examples above, excluding the one from Maaret. To make it clear none of the posts dictate that testers MUST code, but they do appear to give an impression that for testers to make themselves employable they sure should learn how to code.

My temptation was to reply to each of these posts as comments but in the end felt that would not be a great platform to get across my concerns and views on this topic, a topic that keeps coming around again and again.  I am not against testers learning to code but feel that going down this path could have a significant impact on the testing profession in the future.

What do people mean when we say "Learn to Code."?

To the majority of people learning to code means learning a programming language and being able to write an application/script in that language. I can see,  to some, in certain situations where that can be very useful, however do we really need to learn coding or would just having an understanding of the syntax of code be just as useful?

What does this mean when I say syntax?

The Oxford dictionary defines Syntax as:

The arrangement of words and phrases to create well-formed sentences in a language:

Or

The structure of statements in a computer language.

http://www.oxforddictionaries.com/us/definition/english/syntax

E.g.: the syntax of Java or Python.

Having an understanding of the structure of a programming language does not necessary mean you can code an application in that language but you should be able to read and follow lines of code and have a fair idea of what it means and what it does.  The first key point in this article is that we need to move away from creating generic testers who all code to ones that have a fair grasp of the syntax of languages.  This way we will not excluding, what could be, great testers, by turning them away from testing by insisting they learn coding, which is something they may have little or no interest in.  An English major for example could make a wonderful tester by understanding the subtle written words given by a customer to the project team and providing a multitude of creative testing ideas.  Do we really want to exclude these types of people from the testing profession?

This leads on to my next concern, if we insist that all testers need to learn to code we miss out on building diverse teams with many skills that compliment and sometimes conflict each other.  This enables much deeper critical thinking processes and ideas to emerge.  It is a concern that if we insist on testers all learning to code or need to code, then becoming an entry barrier into testing then we could lose a great deal of diversity among software development teams. We instead get a set of ‘cookie cutter’ clones who all code, think and work in similar ways.  This will diminish the testing talent pool, as those who would love to become a tester get set aside for an ex developer who can code but now wants to try their hands at testing. This is not to say that ex developers do not make great testers, we just to need to welcome people with a diverse range of skills and expertise into this great career rather than limit it to those with a coding background or skill set.  Also what do we mean by coding?  I touched on this earlier, within software development coding normally indicates being able to program.  However in social science and especially ethnographic research coding has a different meaning.

Coding is an important technique in qualitative research such as anthropology, ethnography and other observer and participant-observer methods.

http://changingminds.org/explanations/research/analysis/ethnographic_coding.htm

If we insist that testers need to learn code, how about we twist this around and say that testers need to learn social science methods and use that in our testing activities.  To quote the title of the article by Rob Lambert:

“Why testers should really learn to code”

If the code Rob was referring to above was the social science technique and he stated in his article that all testers ‘should really’ learn to do social science coding.  How much debate would that have caused?  If others insisted that every tester should really have this skill and that without it you have a far less chance of being employed as a tester, how would you react? Does a tester having this analytical skill make them any less important to a development team than someone who can do programming? I am unsure if this is the case, since the cognitive thinking skills needed to do programming and to do testing are different as mentioned extremely well in the article by Maaret.

One argument put forward is that testers who can code can create their own tools to do tasks such as data generation, performance, load or stress. I do not see a problem with this but I would add that there are many FREE tools available that may or could do the job without the need to re-invent the wheel. For example for data generation I use Excel  and PerlClip both of which suit my needs.  I have a tool inventory that for the majority of my tool requirements perfectly meets my needs.  I have seen many cases of people writing tools or scripts for the sake of doing so instead of researching or asking advice on tools that are already available.  This is not to say there are situations where creating or writing a tool could be more useful and time saving.  I have in the past done this and my programming skills are not great and I would rate as rather mediocre.

We have to be careful about the barriers we put in place for those who show an interest in having a career in testing.  Sure they need to have certain characteristics such as:

•  A willingness to learn.
• Self-improvement
•  Critical and creative skills
• Plus many more.

Classifying this to one particular skill such as programming rather than a characteristic, such as analytical thinking or logical thinking in my opinion is very narrow minded.

One other aspect that I have not seen mentioned in any of the articles is the issue of bias caused by thinking in a similar way.  If there is a continuing trend to insist that testers learn to code then there could be a convergence towards similar thinking for development and testing.  This may lead to bias in the approach to testing where the effort and focus is on the logical way in which the code works rather than an outward view of how the user may, or may not interact with the application.  Humans are not logical and will not follow the path you expect them to do so.  This is what I feel distinguishes good from great testers, the ability to think critically and apply creative ideas in a way that exposes flaws or issues within the system under test.  If we  continue to insist that testers should really code we could end up with a set of people developing software in which everyone thinks in a similar way and there is no movement from the well-trodden path.

If people have no interest in learning about coding and instead have a passion for testing and how to improve testing then we need to be careful about the message we are sending out from this profession.  I would rather have people working with me who are passionate, driven to learn and improve themselves and others than an excellent coder who want to do just a 9 to 5 job and no more.

I will finish this post with the following quote:

“We are not supposed to all be the same, feel the same, think the same, and believe the same. The key to continued expansion of our Universe lies in diversity, not in conformity and coercion. Conventionality is the death of creation.” Anthon St. Maarten - Divine Living: The Essential Guide To Your True Destiny

EDIT : Corrected some typos.