DevelopsenseLogo

At Least Three Good Reasons for Testers to Learn to Program

There is a common claim, especially in the Agile community, that suggests that all testers should be able to write programs. I don’t think that’s the case. In the Rapid Software Testing class, James Bach and I say that testing is “questioning a product in order to evaluate it”. That’s the short form of my personal definition of testing, “investigation of people, software, computers, and related goods and services, and the relationships between them”. Most people who use computer programs are not computer programmers, and there are many ways in which a tester can question and investigate a product without programming.

Yet there are at least three very good reasons why it might be a good idea for a tester to learn to program.

Tooling. Computer programs extend our capacity to sense what’s happening, to make decisions, and to perform actions. There are many wonderful packaged tools, in dozens of categories, available to us testers. Every tool offers some level of control through a variety of affordances. Some provide restrictive controls, like text fields or drop-down lists or check boxes. Other tools provide macros so that we can string together sequences of actions. Some tools come with full-blown scripting languages that provide the capacity for the tester to sense, decide, and act through the tool in very flexible and specific ways. There are also, of course, general-purpose programming and scripting languages in their own right. When we can use programming concepts and programming languages, we have a more powerful and adaptable tool set for our investigations.

Insight. When we learn to program, we develop understanding about the elements and construction of programs and the computers on which they run. We learn how data is represented inside the computer, and how bits can be interpreted and misinterpreted. We learn about flow control, decision points, looping, and branching—and how mistakes can be made. We might even be able to read the source code of the programs that we’re testing, which can be valuable in review, troubleshooting, or debugging. Even if we never see our programs’ source code, when we learn about how programs work, we gain insight into how they might not work.

Humility. Dan Spear, a great programmer at Quarterdeck and a good friend, once pointed out to me that programming a computer is one of the most humbling experiences available to us. When you program a computer to perform some task, it will reflect—often immediately and often dramatically—any imprecision in your instructions and your underlying ideas. When we learn to program, we get insight not only into how a program works, but also into how difficult programming can be. This should trigger respect for programmers, but it should also trigger something else: empathy, which—as Jerry Weinberg says—is the first and most important aspect of the emotional set and setting for the tester.

Subscribe to the Newsletter

28 replies to “At Least Three Good Reasons for Testers to Learn to Program”

  1. Agreed. Very very valuable. Plus, I mean, it just adds to the resume!
    I asked this question before:
    http://agilescout.com/want-to-be-an-quality-assurance-tester-learn-to-code/

    Like the soft skills you highlighted here.

    Michael replies: Thanks for the comment. Note that I’ve said that being able to program is not essential. Some of the most valuable testers I’ve ever worked with were not programmers. In fact, they may have been more valuable precisely because they had something other than a programmer’s mindset. I’ve also seen software that comes from companies that take very programming-centred testing approaches. Such products often have glaring and embarrassingly poor usability, performance, compatibility, or other para-functional problems

    What I’m arguing for here is diversity on two levels: on the level of the test team, where some programming skills tend to be helpful; and on the individual level, where programming fits with the Karl Weick‘s take on the Law of Requisite Variety: If you want to understand something complicated, you must complicate yourself. There are many ways for a test team to diversify and to find problems, so strike a balance between programmatic and non-programmatic approaches to testing.

    One more thing: I’m beginning to believe that the designation “soft skills” reflects a bias towards a rationalist and technocratic view of the world that dismisses the role of people and emotions. “Soft” skills are among the hardest and most important things for some of us to learn.

    Reply

  2. Agreed, despite the fact that I would have a great deal of difficulty programming my way out of a paper bag. I studied it early in my education, discovered that while I understand ideas like OOP, I just didn’t have the love of code needed to be even a decent programmer. That being said, tool-building has been a motivator lately for looking at learning a scripting language (PHP, Perl, etc.). Haven’t decided on a direction, since I haven’t decided how I want the tool to work.

    Reply

  3. For a tester that has just recently decided to learn (or try to) some programming, this is a timely and valuable post.

    I’m trying to find the happy medium between actually becoming a programmer and only learning the basics. That’s a challenge in itself.

    It’s hard, as like Matt I don’t have the love for code, but do understand the benefits it will bring.

    I’ve ordered the book you recommended MB, so hopefully that will provide suitable guidance to begin with.

    Michael replies: Which book did I recommend? (It must have been in personal correspondence or somewhere else; I recommend a lot of books to a lot of people.) But apropos of this blog post, for testers I can heartily recommend the one-two punch of Programming Ruby (a.k.a. the Pickaxe book) and Brian Marick’s Everyday Scripting in Ruby for Teams, Testers, and You.

    Reply

  5. Likes of Google/Microsoft would take this to extreme limit – as alberto savioa would say “all testing is essentially unit testing”. Testers interview in these companies is essentially solving/writing some java or C code for some data structure problems (at least first few rounds).

    Michael replies: Well, I have great respect for Alberto, but I disagree with him on this point. Saying that all testing is essentially unit testing is like saying that all editing is essentially spell checking.

    I hope one day they ask (giving a program code) and say “tell me how would you test it”. My sources say – that is never the case.

    This brings the central issue here – companies that shape up “software industry” at large – define and use role testers as “step sons/daughters” to developers (or programmers as you would often refer to).

    Its shame that these companies see testing job (almost all of it) as programming job. You not only need to be a decent “production level” programmer, you spend you all life in writing automation or tools.

    No … I am not talking about SDET role – “tester” role.

    Why can’t simply hire programmers for these roles and abolish thing called “testing” and role called tester”

    Why not simply hire people to assemble cars, and abolish engineers and designers? Quick answers: 1) People would hate the cars. 2) People would die.

    Reply

  7. Michael,
    Thanks for the article. I see some books recommended already here. For those of us with no programming experience can I assume you’d recommend reading books on the language you are most involved with as a starting point? For example, the solution I test is in Java so I’m going to start there. Are there any other good starting points for those of us with the aptitude to learn it but no background at all other than years of testing experience?
    Thanks,
    Greg

    Michael replies: You’ll see a couple of references above. I never really learned to program in Java, but I dabbled with Bruce Eckel’s Thinking in Java and liked what I saw. I’ve also browsed through Chris Pine’s Learn to Program (using Ruby as its basis) and liked what I saw there too. Others are welcome and encouraged to weigh in here.

    Another reference that’s handy and helpful, although not a programming book per se is Charles Petzold’s Code: The Hidden Language of Computer Hardware and Software. It tells you about what’s going on under the hood, which can be very instructive.

    Reply

  10. I don’t think that it is necessary to learn programming for testers, but it is definitely beneficial to them if they learns it. They can handle programming and testing both at the same time.

    Reply

  12. I realize your list is unordered, but I might put the point about humility at the top. Just as testers bristle at “…why didn’t you find that bug!…”, a tester might be heard to say “…why didn’t you implement this feature right, it’s so simple!…” Seeing what is involved in implementing even “simple” features can be enlightening.

    The next point about insight is the one where I hear the most objection. The objectors fear they will be unduly influenced by knowledge of the internals and their testing will suffer. To me this just seems like another bias to manage along with all the others testers have to be aware of.

    My favorite reason is the tooling opportunities that open up. I’ve heard “testers should learn to program” get interpreted as “testers should learn to program *so they can write traditional automation.*” If that were the reason, I wouldn’t support it. I think writing testing tools for computer-assisted testing is a strong argument in support of testers learning to program. This has given me the biggest payback for my programming time on the projects I’ve worked on.

    As you said on Twitter, learning to code is a means to many possible ends. Do with it what you will. Thanks for giving us some suggestions for what to do with it.

    Reply

  13. Reading this leads me to the question ‘How much programming should a tester learn?’
    Do you learn just the basic principles , what language(s) do you learn, do you learn Object Oriented programming, learn about various frameworks, if so which ones?
    I find from my own experience that a little knowledge can be a dangerous thing. I sometimes find myslef saying to a Developer, ‘Surely you could just do X’, to which the Dev responds ‘It is not that simple…and don’t call me Shirley’.
    I know there is a lot more I could learn, but I have to ask myself if it is worth knowing, possibly at the expense of other things I could be teaching myself.

    Reply

  17. Thanks for this post! very valuable and inserting to know about the three reasons. Every tester will have this question in mind, To know whether the programming knowledge is necessary to their carrier. I think, this post will be the perfect solution.

    Reply

  23. […] to be valuable to the company. Can coding provide benefit as a tester? Sure, read more on that in “At Least Three Good Reasons for Testers to Learn to Program” by Michael Bolton, but by no means is it required to do what we would consider good testing work. I even caution […]

    Reply
  28. Pingback: Talking Testing with Michael Bolton – Searchability

Leave a Comment