Wednesday, 20 July 2016

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 ""

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

ADD /home/


Example from

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)

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.


  1. Hi John,

    thank you very much for this post and the further explanation to your twitter posts.

    I agree with you in general, that is important to learn skills, which are valuable to the team.
    These skills do not necessarily mean coding skill although I admit I like it when testers have those, or at least have a fundamental understanding of coding. Then again I might be biased since I moved from Development to Test and like anybody else I am hard wired to value my own skill set. ;-)

    I still see a lot of other disciplines that bring skills and knowledge to the table I and other computer scientists don't have. I am thinking of Social Sciences in particular here. Another friend of mine is a a lector and it is interesting to see where the differences lie between lectoring a book and testing software.

    So in short there are a lot of skills that are very valuable for a tester to have (you named some), and for a lot of people it makes way more sense to invest in those than learning to code.

    However, since we are not testing pillows, but software I think it is of utmost importance to have some technical skill, because they will(!) be needed in your project: setup and run a test environment, read and understand log files, use a REST API, find test data with SQL. The exact level of technicality depends on the project.

    I think a lot of the discussions stem from the term "technical skill" itself. It is somewhat fuzzy on the one side and very easy to fill with "coding" on the other side, which is like THE master technical skill. If you say a tester must be a coder you will scare away a lot of potentially great testers, who would not have a problem with, e.g. building test suites in SOAP UI.

    So what we actually should do is define what we mean when we say "a tester needs to have technical skills", it will depend on the project context ... and just claiming she needs to code is maybe not enough thinking on our side.

    That said, a coding tester is not necessarily a second class developer, who is the first to go when budget is cut. I help developers a lot when introducing design patterns, tools or frameworks, which are very specific for checking or other automated testing tasks. I know these things and they don't, because they are simply not needed for their application code.

    So far my (current) thoughts about this. I hope it makes sense.

    Best regards,


    1. Thank you for your comment Marcel.

      I love this line....

      "If you say a tester must be a coder you will scare away a lot of potentially great testers, who would not have a problem with, e.g. building test suites in SOAP UI."

      That has been my concern and again currently I am working towards a devops culture in which coding is not an essential skill but understand the customer, the security risks and uncovering potential issues is far more important than coding. We have enough coders we need more people with testing expertise to ask the difficult questions of the system as an whole. This may or may not required the normalized technical skills but more of a general systems thinking skills set.

  2. I agree, I also think its unfortunate that technical testing is equated to coding skills. There are plenty of technical aspects of testing that don't require development skills.

    I've blogged on this topic also, and my stance is that testers need to be able to showcase, and effectively communicate their skills, and code is just the one that is probably the most understood and rewarded one in most organizations.

    I had a tweak on your analogy about french though, if you working in a country and can read the language but cannot speak it I think you will have a very hard time.

    To have a better time it helps testers to be conversational on code. They don't need to be fluent, and most importantly they shouldn't be scared of it.

  3. This comment has been removed by the author.

  4. Excellent article. Off late I have started seeing some good number of job requirements that say "Technical Tester/Quality Assurance Developer. I used to wonder what do they really mean. Out of excess curiosity I replied to one of those job requirements email asking what is the actual role of this opportunity as the description they had stated was more of a developer thing. The reply was like, current agile environment has created a greater demand of cross functional knowledge and capability. Which would need a tester to have minimal hands-on with the code. This is to avoid some queries and bugs that comes up during testing phase which are actually not a bug. It is easy to have a tester get inside the code and understand what is the what instead of going through a defect to understand that it is not. Hence saving the cost involved in defect fixing. It does not stop here, there are few more additional responsibilities. This creates an opportunity for a tester to get into code, but also scares a tester that his testing job might come to an end because if he has the capability to getting inside the code, understand and can change stuffs. Stakeholders might ask, why a defect when you can clear it off? That's a dangerous scenario I foresee.

    Twitter: @thoughtsofdeva

  5. I am waiting for the day when someone suggests that developers should learn some testing. There are many testers who are completely into automation. Most good testers would love to use tools, learn programming and use automation when appropriate.

    However, I have never seen a single developer who demonstrates an understanding of kaner, bach, bolton, weinberg, let alone blogs like this one (feel free to correct me). Maybe that answers the question posted here?

    btw, I don't think there is a conspiracy of any sort. Category: stuff happens.