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.

Debating and challenging.

“The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum....” 
― Noam Chomsky, The Common Good

There has been a lot of debate, posts and discussions about what is acceptable and not acceptable within the testing community recently and it makes me feel sad and unhappy.  Some appear to have disintegrated into personal attacks and the message has been lost and to me that feels wrong.  Could things have been worded differently?  Of course and hindsight is a wonderful thing.   I am not going to go into detail of these discussions or state who was right or who was wrong.  You can form your own opinions and look up the discussions yourself.

 What I will say is we have to be careful as a community of  limiting the ability to challenge ourselves and allowing others to challenge us.  This should be done respectably  and with the purpose of trying to help us all learn without it becoming a personal attack and counter attack.  As the above quote states if we want to be passive and obedient then sure let us limit what can and cannot be said.  what is seen as acceptable to someone may not be so acceptable to others.  In the same way each individual has their own perspective of what quality is:

"quality is of value to a person" - Jerry Weinberg

I am not closed to the fact that as humans we will often disagree passionately with each other and to me that is OK, however once emotions are involved it can lead to some behaviors which  are not so pleasant. Maybe if you feel in these situations it is best to step back and think before replying.  I try to do that a lot and hence my delay in writing this post.

As individuals we will see the same thing in a different way, hear the same words differently and read into what someone is doing wrongly, hence the unreliability of eye witness in court trials. We may say things which we feel is right  at the time which has unintentional results .   Allowing time for people to explain their intentions and what they meant, is to me respecting each other.   The outcome from this maybe an apology, correction of facts or better clarification of what was meant.

I have to believe that in our community people do not deliberately try to hurt or upset others  however I feel as a community we need to challenge ourselves and others to improve our knowledge and skills.

Let us respect each other even if we do not agree, otherwise people will use this to limit what can and cannot be debated and decide for us what is acceptable to challenge.  At the same time using this to limit what we can and cannot read, listen to and who we can talk to.   To me this starts to become like 1984 and big brother.

To finish we may not always agree with each other but sometimes as the song in Frozen goes we have to

"Let it go"

If the worst thing you get from this post is having that song in your head all day then my job is done. :o)

Technical and Non-Technical Testing Skills

One of the sessions at the Romanian testing conference in Cluj last week was a debate on do testers need to be technical or non-technical. It was an interesting debate and one which causes some great discussions.  One of the first observations was many of the people present were willing to come forward and present the case that testers need to be technical.  The framing of the definitions to me made it difficult to choose which side to present for, since no one had come forward for the non-technical side I put myself forward along with Richard Bradshaw (@friendly tester)  and a couple of other people,  unfortunately their names have escaped me.

The debate was set in the style of one side presented their argument the other side had a chance to reply and then present their side to the various statements that were shown on the screen.   It was a lively and interesting debate and I will keep to the end of this article to let you know which side was voted the most persuasive.

The reason for this article is the issue I have with labeling people as technical or non-technical as if one is better than the other.  I have come across disparaging remarks made against those who see themselves as being non-technical especially if they do not use a computer programming language.   There are the endless debates at conferences, on twitter, in testing forums in which people say you cannot be a tester without knowing how to write code in a programming language.  It is as if you are seen as a second class tester if you do not code or wish to code. Worryingly is this also being reflects in career prospects for testers with many roles requiring testers to become programmers and code. 

The’ testers should code’ debate has been discussed many times and on my blog I have written many articles about this very subject.  (http://steveo1967.blogspot.co.uk/2014/06/a-discussion-on-do-tester-really-need.html, http://steveo1967.blogspot.co.uk/2012/11/testers-should-learn-code.html) However this to me detracts from the issue at hand and what is meant by being technical.  During the debate the argument I presented started with the concept that the word technical has different meanings and that it is dependent on context.   This during the debate was missing from the technical and non-technical statements presented on screen for the debate.  (I did not manage to capture the statements due to being involved in the debate).  One of the assumptions I reached during the debate was that to many a technical tester has one of the following skills:

• SQL
• Programming
• Performance
• Security
• In depth knowledge of the system under test

With these skills the conclusion made was this enabled them to be a better, faster tester who could test the system far better than someone who was non-technical.  These could be good skills for a tester to have and I am sure that in some situations they have value, however they are not the only technical skills a tester could have.

I questioned this conclusion and asked what about those who understand the business, user behavior, the domain – for example finance and the ability to communicate and sell the benefit of testing.  I asked if these were classed as technical or non-technical.   Many said there were non-technical; I disagreed and stated in the right context each of these areas could be technical.  Understanding human behavior and being able to  work out how humans interact and what is their motivation can be a very technical skill. Understanding the value of something to the business and the reasoning why it needs to be done for the benefit of the company is a technical skill.  

In summary the reason for this article is that we in the testing profession need to resist being labeled as either technical or non-technical and simply state we are testers driven by context who apply the relevant skills for that context. 

For those wanting to know the debate was won by the non-technical side.

I would also like to thank the organizers of this conference for a wonderful and welcoming experience.  If you have never been to the Romanian Testing Conference try to come along and attend,  the participates were some of the most engaged testers I have come across at conferences. 

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.