Career Software Testing

Software testers shouldn’t write code

Software testers shouldn’t write code. There I’ve said it.

“If you put too much emphasis on those [automated test] scripts, you won’t notice misaligned text, hostile user interfaces, bad color choices, and inconsistency. Worse, you’ll have a culture of testers frantically working to get their own code working, which crowds out what you need them to do: evaluate someone else’s code.”

~ Joel Spolsky on testers

I used to think that you could/should teach testers to write code (as it will make them better testers), but I’m now at a point where I think that it’s a bad idea to teach testers to code for a number of reasons:

  1. A software tester’s primary responsibility/focus should always be to test software. By including a responsibility to also write code/software takes away from that primary focus. Testers will get into a trap of sorting out their own coding issues over doing their actual job.
  2. If a software tester wants their primary focus to be writing code, they should become a software programmer. A lot of testers want to learn coding not because they’ll be a better tester, but they want to earn more money. These testers should aim to be become programmers/developers if they want to code or think they can earn more money doing that.
  3. Developing automated tests should be done as part of developing the new/changed functionality (not separately). This has numerous benefits such as choosing the best level to test at (unit, integration etc.) at the right time. This means there isn’t a separate team lagging behind the development team for test coverage.
  4. Testers are great at providing input into automated test coverage but shouldn’t be responsible for creating that coverage. A tester working with a developer to create tests is a good way to get this done.

I think the software development industry would be a lot better if we had expectations on programmers to be responsible for self-tested code using automated tests, and testers to be responsible for testing the software and testing the the automated tests. Any tester wanting to code will move towards a programming job that allows them to do that and not try to change what is expected of them in their role.

Update 19th Jan 2015: this post seems to have triggered a lot of emotion, let me clarify some things:

  • A tester having technical skills isn’t bad: the more technical skills the tester has the better – if they can interrogate a database or run a sql trace then they’ll be more efficient/effective at their job – and a tester can be technical without knowing how to code
  • I don’t consider moving from testing into programming by any means the only form of career advancement: some testers hate coding and that’s fine, other’s love coding and I think it would be beneficial for them to become a programmer if they want to code more than they test.
  • I still believe everyone should take responsibility for their own career rather than expecting their employer/boss/industry leader/blogger to do it for them (more about this here).

0 replies on “Software testers shouldn’t write code”

Things are’t just black or white. I am not sure I can fully agree.

I think the points are valid, but there are cases where writing code helps you test (outside anything we call automation). You can code to help you test and evaluate results faster and more reliably (for example if you need to evaluate huge output data sets).

I am a tester who writes code and I don’t think I fall into such traps that you are describing. Maybe it is also a matter of testers own discipline. I admit, that I am sometimes just tweaking my code, but in the end always get back to the reason why I am writing the code – that is, for it to help me see something I otherwise could not easily see.

I do agree that programmers could cover most of the test automation needed themselves. But there it is, now we can get into debate of converting programmers to testers. IMO, testing is skill just as hard to learn and do right as programming. So is it even possible or reasonable for them to do it all?

On the opposite, I was how too much emphasis on automation can be extremely harmful and cause the effects described. Organizations can play large role here. I saw how organizational goal of 100% automation pushed team to do nonsensical automation and still release product with very poor quality.

I think what you are describing is a risk, a warning, rather than straight “never”.

In the end, I think it all comes down to if you understand what you are testing and how to ensure you are testing it right – in the given context.

I think it’s important for a tester to have technical skills (eg. write a script to interrogate a database or logging file) but having them specifically writing code in the form of automated tests is something a programmer/developer should do.

‘Automation’ teams are really just teams of programmers and I don’t agree having them as they are too separate from the system code being written.

I disagree with the premise here. This comes down to what the situation the testers are in.

For example I am testing a product that will go out to customers and will be worked on for years with many planned content patches. In this setting automation tests have a very high value, some tests have been running nightly for over 10 years! They also occasionally find defects I would have missed.

On the other hand when I have worked on the consumer side of applications I understand how testers knowing how to program could be counter productive.

Also I enjoy a little bit of coding, gathering requirements and manual testing! So should I still lean towards a programmer job as you suggest? I don’t think so 🙂

I am testing a product that will go out to customers and will be worked on for years with many planned content patches. In this setting automation tests have a very high value, some tests have been running nightly for over 10 years! They also occasionally find defects I would have missed.

At no point did I say automation tests aren’t high value: I just think they’re better value when done at the same time as development.

Also I enjoy a little bit of coding, gathering requirements and manual testing! So should I still lean towards a programmer job as you suggest? I don’t think so 🙂

Programmers aren’t excluded from gathering requirements and manual testing: in fact, a good programmer does all of those things as that as well as programming.

Sorry Alister, I too disagree with what you’ve said here.
To me, writing code for automation is just another tool that testers can choose (if they wish) to improve the quality of their work. I understand your statement about getting too involved with the detail of solving coding problems at the detriment of providing quality, but I don’t agree with it 😉

In our team, pairing and walkthroughs of test coverage at all levels allows what we used to call ‘developers’ become more skilled in testing, and vice versa for what we used to call ‘testers’. This addresses your first point, where the responsibility of testing is the team’s, and echoes your third and fourth points – maybe I’m missing your argument, but a tester developing reusable automation code in parallel with the implementation of application code isn’t a compromise on quality. I don’t see any loss in testing focus, I just see better efficiency.

Point 2: ” A lot of testers want to learn coding not because they’ll be a better tester, but they want to earn more money.” Sadly, I disagree with this statement too – in my experience, skills across a good team are valued equally. If they’re not, then the team’s culture or management isn’t conducive for building software. Also, I’ve yet to find this elusive ‘stepping stone’ career move of tester to developer. Do you have any evidence for this?

What you’re suggesting sounds dangerously like an exclusionist principle where testers would be denied the opportunity to explore more technical areas in work. This is a concern particularly in the more progressive agile methodologies where the team has a strong focus on multidisciplinary personnel.

Sorry Alister, I too disagree with what you’ve said here.

Don’t be sorry, it’s good to have different opinions: it means one or both of us is about to learn something and hopefully change their mind (even if ever so slightly) on something.

Just like my response to a comment above, I think it’s essential for a tester to have technical skils (perhaps my post didn’t convey that), but when a ‘tester’ is writing more (automation) code than testing, I don’t think they’re a tester anymore: more likely a developer, or software engineer in test or whatever you want to call them.

As for your second point, I get A LOT of emails from testers asking how they can learn coding/automation (or expecting that I teach them!?!) so they can advance their careers/earn more money. I didn’t make that observation up.

This makes me very frustrated as I think everyone needs to take control of their own career, there’s no ‘exclusionist principle’ at play: you’re in full control of your own career. If you want to be more of a technical tester, do it. If you want to learn to code: do it. The bar has never been lower. (read:

If I found myself enjoying coding more than testing I would aim for a role where I can do more of the former and less of the later. And I believe that role is a software developer or software engineer in test, not a tester – it’s not a step up by no means – and I never said it was, it’s just an entirely different focus.

Happy to discuss over tea.

I wholeheartedly disagree with this article and you really have failed to grasp the essence of the modern day tester – look up T-Shaped tester by Robert Lambert which suggests that in a cross functional agile team, all members have a core skill a set of horizontal skills – a set of general skills of which writing code is one of them. (Read the article ‘The modern day tester’ by QAWorks.) Furthermore, when I interview testers I want to make sure they have a general understanding of the .Net stack or any other development platform. Testing is about learning, exploring and understanding, and finding bugs is a small part of that activity so if I interviewed a tester who states that they’re a fantastic manual tester but has no clue whatsoever about how to code, I would have reservations. I love testing, and wish I had got into it sooner than I did as I was a software engineer for 16 yrs. But with my experience, I have carried it forward into testing quickly gaining respect and surpassing most of the manual testers who have done nothing else. Lastly, I’ve found dedicated manual tester seeing testers such as myself as not testers but programmers. They’re what I call the dinosaurs of the testing profession and soon hopefully become extinct. For me, I enjoy manual testing and sometimes, whilst doing automation I yearn to break the software by using my manual testing skills. Do that means I’m always a tester first and programmer second.

I see that a lot of people see “tester writing the tests” as the one doing his UI-automation tests, which are, in fact, supposed to be done separately from programming. I still think there is an underestimated benefit from tester writing blackbox unit-tests for the code.
Consider test-design activity for manual testing – it is writing the black-box tests, isn’t testing? Of course it is. The same is for me regarding coding black-box tests against the class-interfaces, it is not primarily coding, it is testing too.

A tester who can code well is not necessarily a better programmer than he is a tester, in some cases he loves testing much more than programming. Coding is necessary for programming but coding along is not at all enough to became even mediocre programmer.

There’s a dramatic difference, in my view between “testers shouldn’t write code” and some alternatives:

– testers shouldn’t write code if it results in them being fixated on writing code
– testers shouldn’t write code when the costs of doing so outstrip the value that it brings to the project
– testers shouldn’t write code to produce automated checks when it make more sense for the programmers to write those automated checks (which is typically the case)
– testers shouldn’t write code unless their role is to provide toolsmith support to other testers
– testers shouldn’t write code if they’re not motivated to do so; instead, they should recruit helpers to do so

On the other hand…

– testers should write code if it helps them to perform valuable tasks more efficiently than they would otherwise
– testers should write code if their desire is to help to visualize or otherwise develop a deeper understanding of something (for example, writing a Monte Carlo simulation played an important role in this series of blog posts)
– testers should write code if they wish to learn in a visceral way that programming is not as easy as it seems
– testers should write code if they wish to learn how to read and understand code (and other aspects of the product) with greater expertise
– testers should write code when the tools that are available do not fulfill an important need that the tester can supply

You see? The blanket admonition “testers shouldn’t write code” is as unhelpful as the one that we see far too often, “testers MUST write code”. With prescriptive advice, it might be a good idea to consider context taking precedence over dogma.


—Michael B.

“… I don’t think they’re a tester anymore: more likely a developer, or software engineer in test or whatever you want to call them.”

In my (humble) opinion, you’re making a very clear distinction here. You’re referring to “tester” as a purely manual (a term I dislike but can’t find a good synonym for right now) & blackbox role, and as soon as automation becomes involved the title changes to “engineer” or “developer”. I strongly dislike the hard line in the sand being drawn here. I believe a tester should be able to do what is required to get the best test coverage of the feature or product under test. That is almost always a blend of automated and exploratory testing, sometimes coupled with coded scripts to ease workload or help in various other ways.

The timing for this post is interesting, as I have just written a blog post a few days ago on testers writing code (and doing other things!). I think we’ve done our industry a disservice by giving people who write code a different role title. It creates the exclusionary mentality we see captured in your post.

However, I do agree with what you are saying about moving testing upstream instead of making it a “post-feature-development” activity. Where this goes wrong is that you want the developers to spend more time writing all the test scenarios we can think of, from unit testing right through to UI testing. This seems like an invaluable use of a dev’s time when testers can provide assistance here, but you are saying they should be reserved for feature end-user blackbox testing.

A model that has worked for us in the past was a small blended team made up of developers and test developers. Their primary focus was on maintaining our automated testing frameworks, and constantly improving the frameworks to make the writing of the tests rather simple. This allowed testers on the various agile development teams to write tests without having to worry too much about spending time debugging their code (as it was handled by the framework and its support team). I believe this helped mitigate the problem you are proposing – where testers time gets tied up in making their code work, and thus detracts from the focus of actual feature quality.

Feel free to read more of my thoughts on the matter over at:



Wow amazed you go all out on this. To some extent I think you are right but I also think that reality looks a little different i.e. suits itself to a different view.

Yes I agree that testers with coding know-how will have it easier to get hired and maybe for a little more $$$$$. But that is a minor point to where you are going with this.

I think what it comes down to (again!!) is the whole discussion testing vs checking. In test automation we do checking and as you quite rightly say one can get lost in that side of the world. Which isn’t necessarily a bad thing but it is definitely something you need to be aware of constantly. For years now I have successfully stressed the difference and it makes talking about automation just so much easier. It puts the use and place for it into the right focus.

In my experience it takes a special type of person to be that “technical tester guy/gal”. It is more around interests and affinity than actual development know how. So far I can’t quite put a finger on what it is but usually I know one when I see one. Whether you still want to call that person a tester is up to you. There is probably just as much reasons for calling her a developer. But what makes me still class her as a tester is the actual interest in testing/checking software rather than creating it. I also think if you’re unable to contribute code (not test code) to the project that disqualifies you from being called a developer.

BUT!!! You are doing development like work and as such you need to have all the skills and practices of a developer! I see too many technical testers ignore that little fact.

Getting developers writing test code is a very bad idea in my book. For the following reasons:

1) Developers are interested in writing application code and I fully understand that. Often enough you can barely get them excited to write unit tests!
2) Developers are measured against how much application code they get done. This is a common management mistake.
3) When crunch time comes (and it ALWAYS does), what do you think will suffer first?
4) Assertions, assertions, assertions! I have enough problems with testers not doing them right. All down-hill from there. Or have you never seen tests without a single assertion? 😉
5) Developers generally lack the affinity to defects that testers have. That would ergo make them bad automation testers too. Now you’d need a tester to check their tests which is probably less efficient (might be different for pair development).

Now of course there are lots of exceptions here! Of course not ALL developers are like this and not ALL projects fit this scenario but I still think there is the “developertestersuperstar” that fits exactly into that gap. I’m guessing you yourself are one of these persons.

So instead of lumping them into one or the other “camp” I’d suggest just accepting the fact there are these people out there.

What I am convinced off though is that you can’t just take a developer or tester and make them into this kind of person! As I said, it takes a certain cross section of knowledge and interest to fit this profile and if you find them you SHOULD be paying them copious amounts of money as they are the hen’s teeth of testing folk.

Cheers Oliver

Btw, just for the record I exclude performance and security testing here as they cannot be done without applying automation in large parts).


Good Article although I can see where it can be interpreted in different ways.

Here is my opinion now that the topic is out and we are all exchanging different opinions. I am approaching this from purely a Quality Assurance point of view with a caveat that no one shoe fits all. I have my masters in Software Verification and Validation and this is what I have learnt and put to practice and think is what is lacking in lot of organizations. I may be wrong!

The lack of knowledge of what to verify and what to validate is prevalent in lot of companies. Being a test engineer I hate to say this but in my opinion a lot of testers do not have that background and knowledge of V and V, let alone programming principles and coding experience.Is it good for them to have all that knowledge? My answer is always going to be Yes.

But, from a V and V stand point, the word REGRESSION is the emphasis to catch impacts/defects/bugs/issues that may have been injected as the software code bank keeps increasing. Now in order to perform Regression Testing, there are only two ways of doing it. One, execute all the test case scenarios of features/functionality manually, or the other, leverage code to do the job all or part of it for you. To get the maximum ROI for any project automation is the only option rather than human beings!

Now coming to that decision in my opinion is not very difficult. Time/effort and few other indicators of a feature/functionality will give us that answer. If a feature/functionality is not going to change at all and its impacts are low and risks are low and business value is also low, one may need to rethink if it is worth automating it. Only those test case scenarios that are complex, are high risk or of high business value, or keeps changing frequently or impacts many other functionality, then those would be ideal candidates to automate. Now there may be enough resources for a project to go the fully automated route or it may not. Neither of the above mentioned points should take the focus of a test engineer from testing. End of the day, he/she needs to Verify and Validate that the feature/functionality is working as expected by the customer. Whether he/she decides to do a pure manual approach following which automation of few/all scenarios take place or whether he/she decides to do a hybrid approach of performing manual/automation execution at the same time or only leverage automation code to perform all the V and V for the feature/functionality it does not matter.

The only reason I see the above equation failing if a tester takes on the effort of automation for the right reasons but ends up after a few months with bad coding practices in a soup where he/she is spending time providing TLC to the flaky automation code that has not been designed with abstraction, scale ability and maintainability in mind. Unable and/or unwilling to do it the right way is where it all boils down to. If a test engineer does not have what it takes to do both V and V and also put together a regression bank of tests that are written with the best patterns and architecture then they should defer that job to someone who can do it for them. If they have what it takes to do it, then by all means they should.

Gurushyam Mony

Alister, I agree with much of what you say, especially the part about testers learning to code to make more money. However, I think that the core problem boils down to the obsession that the industry seems to have with UI automation a la Watir, Selenium, etc.

I work at a Watir shop, I like it better than Selenium (which isn’t bad) but I always avoid programming UI tests as much as possible. Also, I can’t tell you the number of times I’ve seen testers write large suites of automated UI tests while never automating all the mundane things that they do every day e.g. installing/deploying a new build, grepping logs for errors, building test environments, etc.

IMHO, it very much depends on what other roles you have in your organization.

I’m fairly certain that testers writing unit test code is largely the wrong thing to do. However, writing BDD/cucumber style tests makes some kind of sense.

– Testers *should* define the test cases in structured language (Gherkin), unless you have a competent enough product manager to do that.
– Test automation engineers *should* automate the test cases. If you don’t have that specific role, a tester may do it instead. I would stay away from letting developers to it, because a black box approach works best for BDD.
– At least one tester in your organization *should not* be busy automating test cases.

That’s a lot different from just saying “testers shouldn’t write code”. It’s all about ensuring everyone can do what they do best.

Could discuss further, but let’s leave it at that for now 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *