Do software testers need technical skills?

This post is part of the Pride & Paradev series.

Do software testers need technical skills?

Software Testers Need Technical Skills

“Man is a tool-using animal. Without tools he is nothing, with tools he is all.”
~ Thomas Carlyle

You’re testing software day in and day out, so it makes sense to have an idea about the internals of how that software works. That requires a deep technical understanding of the application. The better your understanding of the application is, the better the bugs you raise will be. If you can understand what a stack trace is and why it’s happening, the more effective you’ll be in communicating what has happened and why.

“Most good testers have some measure of technical skill such as system administration, databases, networks, etc. that lends itself to gray box testing.”

~ Elizabeth Hendrickson – Do Testers Have to Write Code?

As you’re testing, you can easily dive into the database and run some SQL queries to make sure things actually did what they were meant to, or discover and test an exposed web-service using different combinations as it’ll be quicker and provides the same results.

You’ll know IE7 JavaScript quirks and will be able to communicate these to a programmer and work on a solution that gracefully degrades.

Gone are the days where you’d be emailed a link to a test environment somewhere that you’ll use to conduct some manual testing and provide some feedback. More often then not, you’ll start by setting up your own integrated development environment on your own machine so that you can pull changes as they’re committed by programmers and find issues sooner.

You’ll also probably be asked to build a test environment that other people can use, and a continuous deployment pipeline to automatically update that environment when appropriate.

Without technical skills you’re going to struggle with this, as it’s not just a matter of testing’ the functionality of the application, but testing the entire system: that it can be built, deployed, internationalized, scaled etc.

Soon you’ll start coming across other testing challenges such as how to test internationalization and localization, accessibility and how to locate or generate appropriate test data. This may involve writing your own SQL scripts that take field labels and translate them to a test locale to check screens for hard coded data. Again, these activities require technical skills.

Often programmers will show disdain for testers without any technical skills as they won’t understand the technical challenges a programmer faces, and won’t be able to communicate issues in a technical way.

The more technical skills you have in your toolbelt, the more effective you can be as a software tester.

But having strong technical skills and wanting to do nothing but programming as the sole tester on a small agile team is a recipe for disaster.

Software Testers Don’t Need Technical Skills

“A particularly terrible idea is to offer testing jobs to the programmers who apply for jobs at your company and aren’t good enough to be programmers. Testers don’t have to be programmers, but if you spend long enough acting like a tester is just an incompetent programmer, eventually you’re building a team of incompetent programmers, not a team of competent testers.”
~ Joel on Software on Testers

Hiring testers with technical skills over testing ability is a common mistake. A tester who primarily spends his/her time writing automated tests will spend more time getting his/her own code working instead of testing the code that your customers will use.

In a small agile team of say seven programmers and one tester, the tester will spend nearly all his/her time conducting exploratory and story testing so there will be no time to spend as a tester writing automated tests, it will need to be done by the programmers as part of developing a story. Hiring a tester who expects to predominantly write code on a small agile team is a big mistake.

“Since testing can be taught on the job, but general intelligence can’t, you really need very smart people as testers, even if they don’t have relevant experience.”

~ Joel on Software on Testers

What technical skills a tester lacks can be made up for with intelligence and curiosity. Even if a tester has no deep underlying knowledge of a system, they can still very effective at finding bugs through skilled exploratory and story testing. Often non technical testers have better shoshin: ‘a lack of preconceptions’ when testing a system. A technical tester may take technical limitations into consideration but a non technical can be better at questioning why things are they way they are and rejecting technical complacency.

Often non-technical testers will have a better understanding of the subject matter and be able to communicate with business representatives more effectively about issues.

You can be very effective as a non-technical tester, but it’s harder work and you’ll need to develop strong collaboration skills with the development team to provide support and guidance for more technical tasks such as automated testing and test data discovery or creation.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

10 thoughts on “Do software testers need technical skills?”

  1. So well said! There is a balancing act if you’re a highly technical tester who enjoys coding tasks such as test automation, but the team really needs help with manual exploratory testing too. Conversely, if you don’t understand the system architecture well, or you don’t know enough programming concepts, the programmers will feel they can’t communicate well with you. Frustration all around.

    I find that pairing with the programmers is the most effective way to continue to build the techy skills I need in addition to all the other testing skills in order to contribute well on my team. As Janet Gregory says, we need to be testers with T-shaped skills.


  2. I’m the sole tester on a team with 8 developers. I have spent far too much time automating core tests, but I always find I am really thankful for spending that time when an update is made and I need to run broad regression testing.


  3. “What technical skills a tester lacks can be made up for with intelligence and curiosity”

    I don’t agree, which is a shame in a way as I was cheering along up till that point. What Joel misses, and what you appear to be missing here is that a lot of experienced non-technical testers haven’t developed technical skills & knowledge because developing really strong testing skills takes serious time and commitment, and they’ve made a conscious decision not to split their focus. Being a strong exploratory tester isn’t all about being a better customer, or having better business domain knowledge – business knowledge & good collaboration skills are certainly important, but it’s a mistake to look at a skilled tester & put their success down to those alone. I talk to people who are strong in those areas & test, & they don’t really have that skill at modelling, applying different techniques to reveal different sorts of problems, being able to frame/change frame effectively. Not that they can’t develop it, but they haven’t yet.

    After I graduated from my CS degree I chose to focus on developing strong test skills, even though that meant letting some of my tech skills atrophy. It’s only now, about 6 years later (& after 9 years overall in testing) that I’m feeling that I really can start defocusing from my core skills again without becoming a worse tester. I don’t think everyone should follow my pattern (a diversity of approaches makes a stronger team) but I think it’s really important not to make the tech vs non-technical tester debate sound like the “strength” of a non-tech approach comes from innocence rather than systems thinking, psychology, etc. You haven’t quite gone there, but you’re sounding close to it, if you see what I mean?


  4. I don’t think I’ll ever understand why, but it’s always such a battle to prove oneself as technical in a testing position unless you are the automation silo which is it’s own, separate topic. Maybe it’s the bi-product of working with code that ultimately reduces down to binary values. You’re either a tester or a developer. You’re either technical or you’re not. Thanks for writing about the land in-between.


  5. Great discussion. I wonder if it is worth mentioning how strange I find it that typically, conversations about “characteristics of testers” tend to navigate towards common skills or attributes. There is often a notion of a homogeneous persona pool. I rarely see this when discussing project teams or even developers in general.

    Is the creation of a skills and attributes depth chart something that is rarely available when hiring software testers? A collection of stars who complement one another and slide in and out of projects to assist one another based on their natural talents, skills, experience or expertise? Ideally, when I look at this discussion, I would like to have a team with both… but specifically, I would want them to then be a team.


  6. Technical Testers are something I strive to develop with every new hire I make.
    I don’t expect that they’re necessarily technical when they join, but I do encourage and support them to become more technical.
    Part of this is my own bias- I never had a choice of being anything but technical- especially at Microsoft where being a system administrator and programmer was just part of the job.
    It was amusing to hear people called it (administration) a separate profession!

    As far as I’m concerned- my professional mission as a tester is to raise the technical bar of testing across the board. I don’t profess to be a great writer, or a great Agile coach, but I work bloody hard at being a good technical tester and I hope others share my journey.

    I feel very strongly that we are all let down by testers who either have no technical skills, or no desire to learn any.
    A tester willing to get their hands dirty sets a great example to others who have a curiosity to learn and be challenged.


  7. As others have commented, it’s a hard balancing act
    Current books I’m reading:
    Impact Mapping – so I can test assumptions early on in the process
    Cucumber and Cheese – to know more about this, what the devs are writing and what use I could make of it in my testing
    Tacit and Explicit Knowledge- so I understand more about what I do and dont know
    Only one of those books would be classed as technical, does that mean I’m wasting my time reading the others ?

    I hang out on Hacker News a lot so I ‘m familiar with a lot of the tech terms but if I start dping deep dives into jQuery, Ruby on Rails, SASS, Clojure, NOSQL, MongoDB, Haskell then where do I have the time to dive into usability, mobile, security, performance

    Nice post, looking forward to more in this series


  8. I agree with some of the other comments. It’s a choice (for me anyway). I would love to more technical skills (outside of those I learn at work), but I love learning about the other parts of testing more. As Phil mentioned, time is the killer.

    Given the choice between learning about Ruby or learning about usability concepts, I choose usability. I’m guessing that will change at some point, but right now it’s what suits me.

    My current role has ‘forced’ me to learn more SQL, and it’s cool… but it’s the role that’s driving it.

    All /good/ testers are technical, and have technical skills; you just need to be aware that almost all of them will have a different definition for the word technical.


  9. Why would you need technical programmers let alone testers? They just need to be smart and start from “Hello World”. In a month or two with the help of Google they can be working quite productively.


Comments are closed.