What do we mean by testers learning to be technical?

I recently read a post by Justin Rohrman entitled "Do testers need to code".  The following line gave me some concerns:

"So, I think that testers do need to learn some programming skills now."

Now I wish to begin by stating I am not against testers learning to code  if that is something they are interested in and they want to learn.  On the other hand it may not be the best value skill you could bring to a team, especially if you already have 5-6 exceptional coders on your team.   Justin within the article tries to align to this thought with the following:

"My new feeling is that testers need to learn to program, or at least become more technical –write SQL, use developer tools effectively, read code — for any sort of longevity in the field. "

I have blogged about this in the past- 'A discussion on do tester really need to code.' in which I talk about adding value by learning the syntax of code.  I was asked on twitter by Marcel Gehlen to provide an example of what I meant by this.  I replied with the following:

'I understand the syntax of the french language but I am terrible at speaking it.'

The main point of this update to the 'testers need to code' debate is around what we mean by being 'more technical'?  To the majority of people and from the many articles I come across this implies learning to code.  I feel this is too narrow and at the same time limits the potential and opportunities testers may have.  As an example if you now have a team in which everyone can code and there is a need to reduce the team due to financial and business pressures.   If the decision being made is based upon coding skills then I feel testers could be at risk.

Where does this learning to code end?    In the modern development world of 'devops' are we now going to state that operational people and marketing people should now learn to code?  we could end up with an over saturated market of half decent coders.  What skills are going to make testers stand out and be seen to be adding both team and business value?

Taking a step back what do we mean by coding?

I can writing scripts in bash which to me is similar to writing test script in the sense of logical following steps.  At the same time I understand the command line interface to enable me to deploy a test environment.  Going forward into the devops model I can write dockerfiles to create containers..

#
# Super simple example of a Dockerfile
#
FROM ubuntu:latest
MAINTAINER Andrew Odewahn "odewahn@oreilly.com"

RUN apt-get update
RUN apt-get install -y python python-pip wget
RUN pip install Flask

ADD hello.py /home/hello.py

WORKDIR /home

Example from http://odewahn.github.io/docker-jumpstart/building-images-with-dockerfiles.html

I understand how to use ansible to deploy an environment to enable me to test and run automated checks.

These are, what many would class as, highly technical skills.  However as Jerry Weinberg just posted about 'Becoming a Better programmer; ' there are other skills that are of value to a team and to the business that many would not class as technical.  The ability to get people to work well together and collaborate and communicate is a highly desirable skill to have.  Since it is classed as a soft skill not a lot of emphasis is placed upon this as a skill testers should learn.

What about analytical skills, as more and more companies move to a devops model for software delivery, the skill of being able to determine patterns within the software from all the data and collate that data to help improve try and improve the quality is a highly demanding and technically challenging skill.  I can see this skill becoming highly desirable in the future.  Maybe a tester could invest their time learning this skill?

Then we have the other areas such as an understanding of human behavior to help influence the design .  Learning about social science and systems thinking to help see the big picture and overcome obstacles for the team.   I have been running a series of blog posts on skills testers should learn away from the traditional 'must code' school of thought.  Using your time wisely to practice and improve these skills can help you become a better tester and more importantly show your value to the business.

A few examples are given below (feel free to browse my blog for other examples)

• http://steveo1967.blogspot.com.co/2016/06/testing-skills-10-persuasion-and-selling.html
• http://steveo1967.blogspot.com.co/2015/11/testing-skills-8-being-skeptic.html
• http://steveo1967.blogspot.com.co/2015/10/testing-skills-7-reflection.html

Also with your testing skill set you could mentor, coach and teach others about testing and how they can use that to help improve the software.  Set yourself a goal of coaching the programmers in simple test techniques that they could look to add to their frameworks to enable you to focus more on the difficult to find issues using exploratory testing .

Again I wish to state I am not against tester learning and if they feel they have a passion towards coding then go and do it.   At the same time think about what else they could learn that adds both team and business value.

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.