(Not) Lying about Writing Code

I recently saw this quote in an article by Nikita Hasis on Medium.

“If Your Test Leaders Aren’t Telling You To Write Code, They Are Lying!
Even if it’s by omission.

There’s this argument, almost daily, about whether software testers should learn programming. I’ll jump right in. It is unimaginable that someone would tell you NOT to learn something. That’s the first, and probably shittiest lie that inexperienced testers get fed. It’s further unimaginable, and downright irresponsible to tell people not to learn something that is very clearly where a large, well-paying, and above all interesting part of the industry is heading. Wanna work on innovative, data-driven projects with smart and driven people? You probably need to pull up terminal and at least get your toes wet, y’all.

The worst part of the lie is that it imposes that coding is a difficult grind and will only cause more problems than it solves. I even saw Alister Scott’s blog post referenced as an argument against coding, ironic as it is.”

~ Nikita Hasis (Medium)

Since Medium is a walled garden that doesn’t allow you to leave a comment without creating an account I’ll leave my response here instead (where anyone is free to comment however they like).

I’ll start by saying this is a really difficult and highly contextual subject filled with emotions like job insecurity and last time I wrote about it a lot of that emotion was released, which I regret.

I’ll try to clarify my current viewpoint and try to remove any emotion and hyperbole from it.

I disagree with the overall premise of the article, but some of it makes sense. I found the lack of distinction between tester and test engineer somewhat confusing, as I will highlight below.

As a test leader, I wouldn’t tell software testers that they must write code, and I wouldn’t be lying. But I also wouldn’t tell them not to learn programming skills.

There’s a huge difference between not telling software testers they must write code and also telling them they should not learn something. Telling someone to not learn something goes against all my views on personal responsibility for professional development, and after all I have taught myself numerous programming languages and tools like Ruby, Watir, C#, WebDriver and JavaScript (ES6).

So, my current point of view on this topic is:

  1. Software testers can be effective both individually in testing software, and as a team in releasing high quality code, without personally writing code.
  2. Software testers can be more effective if they have technical skills and a deep understanding of the application architecture they are testing. Whilst there is a strong correlation between technical skills and programming skills, I have also met many software testers with strong technical skills without strong programming skills. This includes being able to use a command line terminal (as mentioned in the article), mastering text editors, and querying database tables and APIs.
  3. Software testers can be also be more effective as testers if they understand the programming language of the application they are testing – but this is by no means necessary – see points 1 & 2.
  4. When teams consist of developers that aren’t writing self-testing code themselves, if that team wants to be able to release high quality software frequently they will often dedicate someone, or some people, to programming (often full-stack or e2e) automated tests separate from development. This person must have programming skills, but I would not call this person a ‘software tester’ as their primary role is not to test software, but rather to develop automated tests (which helps the overall team goal of delivering quickly). This role is often called a ‘software engineer in test’ or a ‘test engineer’, amongst other names.
  5. Some software testers learn programming skills, but wish to remain a software tester, not become a test engineer, or application developer. This is great if these skills help them be a better tester and they are happy primarily doing testing.
  6. Some software testers are interested in becoming a test engineer so they go about learning programming skills. This is great.
  7. Some software testers or test engineers love programming so much they want to become application developers. This is also great.
  8. Some software testers love testing software so much they want to be a software tester without writing code. This is also great. If they were in a software testing role, I wouldn’t tell these software testers they must write code (and I wouldn’t be lying).
  9. Writing full stack/e2e automated tests for existing applications can be a difficult grind – hence our industry wide problem of ‘flaky tests’. This can be solved by writing better more testable systems – which is done by more collaboration between application developers and developers of automated tests.
  10. I have noticed a broader industry trend to have less software testers who focus on software testing and more test engineers who focus on developing automated tests. I believe this may be due to a general consensus that manual == bad and automated == good, which I don’t believe is always the case as it doesn’t always lead to a better end user product. But this belief may lead to test leaders telling software testers to write code (such as mentioned in the original article).
  11. It’s possible for a test engineer, or an application developer, to also have software testing duties, but I have seen quite a few cases where test engineers or application developers consider themselves ‘beyond manual testing’ and won’t do it. I don’t agree with this.
  12. If you end up in a situation where you only employ test engineers, or software testers with programming skills, and these test engineers or software testers purely want to write code (and not do actual software testing), you’re in a very bad situation. I have seen this happen.

I personally would consider my current role to be test engineering focussed as I am required to have programming skills to write end-to-end tests, but I am also expected to take on the responsibilities of testing new software features that are released: even though this does not require me to have programming skills. I like this balance.

There are currently three people in our team I would consider to have software testing roles (they have various experiences from novice to expert in programming – but focus predominantly on software testing), and two people I would consider to have test engineering roles (who are both experts at programming but also do software testing).

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

9 thoughts on “(Not) Lying about Writing Code”

  1. Well said. #9-12 are important because this “automation = good, manual = bad” attitude is becoming more pervasive. I think all automation developers should also be considered testers, because there are a lot of small choices to make while writing automation, and those choices involve making the same types of priority calls on the testability, likelihood of failure, and business value that other types of testers make. It’s important to approach automation with a “tester’s mindset” rather than a “developer’s mindset”; otherwise the suite becomes over-engineered and it will test for things that very rarely fail.

    I also agree that a tester does not necessarily need to know how to write code. But, in keeping with the point of the original article, I wouldn’t want to work for a company that tells me not to learn something when I want to learn it and it will improve my job performance as described in # 5-7. Fortunately, a lot of companies have good managers who will encourage testers to learn to code as we grow in our careers.

    Liked by 1 person

    1. Thanks for your well thought out response fulvius4.

      otherwise the suite becomes over-engineered and it will test for things that very rarely fail

      I have seen this happen way too many times


  2. Interesting … TBH I think any silo role will attract cost-focussed managers who don’t see the value in a QA cross skilling. At one client, I asked the test team if anyone knew how to code, as the customer was looking to up-skill some of them into coding QAs, but had concerns as the team had all been drafted in cheaply from an agency.

    I asked “can anyone code?” and eight hands went up – Java, C#, Java, C++, JavaScript, Ruby. They all had degrees in Comp Sci. Now, there was a team with talent to burn, but they had been pigeonholed as manual testers due to the usual cost-silo thinking. Those sorts of narcissistic managers often hold back their organisations, stifling engagement and innovation, in dreaded fear of their KPIs.

    Testing software goes back to Dijkstra and how it’s necessary to “understand the mechanism” in order to test something effectively – you need to understand how your input examples are sampling the program’s state spaces, see https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html Software is designed to be tested, so not a task a developer or designer can hand off – it has to be a collaboration and the software needs to be designed to be tested based upon a range of stakeholder input.

    TBH I think coding is the easy bit – most systems are v simple – understanding the nuances in software design is more difficult, so unless you want to do lots of pointless manual testing, learn to read code and mentor developers about how they should approach software design. :)

    Liked by 1 person

    1. Thanks for your thoughtful response Ken.

      TBH I think coding is the easy bit – most systems are v simple – understanding the nuances in software design is more difficult, so unless you want to do lots of pointless manual testing, learn to read code and mentor developers about how they should approach software design. :)

      I agree absolutely. Designing for testability and accessibility are two key things that come to mind.


  3. As in nearly all things there is value in balance.

    all automation no manual is bad.. repeated execution of the same test rarely finds new bugs, and really only tells you if you broke something that was previously working. Valuable yes, but not sufficient as undiscovered bugs stay undiscovered.

    All manual no automation is bad.. you end up having skilled testers repeating the same tests (for regression) which is not a good use of their time. Or you skip that, and miss when you broke something that was previously working. Granted you will likely find more bugs in new code, especially if the testing is not just ‘scripted checking’.

    A mix of the two is usually best, Automation to alert you when critical golden paths are compromised, and manual testing to find new bugs in new code and undiscovered bugs (not found by existing automation) in existing code.

    The smaller the team, the more important that your ‘tester’ can do both, and is not specialized at one or the other. OTOH on larger team there is for sure room for both manual and automation specialists. And in my experience a skilled experienced tester using Exploratory Testing will find more bugs than are found by automation written by a skilled SDET.. BUT only if they don’t have to use 50% or more of their manual test time doing regression testing due to a lack of automation.. The automated tests are what empower the manual testers to be their most effective, by allowing them to do mostly ‘new tests’ instead of repeating existing tests.

    Liked by 2 people

    1. Thanks for your response Chuck.

      I agree absolutely it depends on your context and smaller teams typically require a broader skills set with less specialism, and the ultimate value is in balance between the two.


  4. As someone that just moved from a client-facing consulting role into a testing role, I found this very interesting. I happen to really enjoy writing code, and see myself more as a “test engineer” as opposed to “tester,” but had not previously even understood the distinction, let alone thought about the value of testers that focus on testing rather than writing tests. I kind of assumed everyone in testing did both (as I have to in my new role) but I think it definitely makes sense to have a good mix of those that focus on the automation, the manual/exploratory testing, and then plenty of people that do some of both along the spectrum.

    Keep the posts coming! Very insightful for newbies like me :)

    Liked by 1 person

  5. Hey Alister!

    First of all, as a long time reader of your blog I was a little surprised that you took the time to read and reply to my blogpost! It’s a giddy moment for me, and it gets me even more excited about our community!

    A specific LinkedIn comment thread triggered my post on medium. This thread cited one of your posts as the be-all-end-all proof that testers should not write code. One of the things I’ve most enjoyed about your writing over the years is the both-sides perspective, real situations are far more subtle than black and white. I’ve read Pride and Paradev around the same time I was starting to “smarten up” about the industry, and I’d like to believe that it played a part in shaping my current work ethos and the selfless, team-first paradigm I espouse. I realized that I can be a great contributor if I do whatever it takes to help my team move forward, and that was the point I tried to make. On a particular, well compensating style of team, this requires a coding skillset is a tremendous advantage.

    This is not necessarily about writing automated checks or cukes or “100% automation” — it’s about being able to step in for what your team needs. These are influential roles on groundbreaking, fast-moving, lean teams, that are there for the taking, and we happy generalists are perfect candidates to take the reigns.

    I agree with everything you say above, except that I do not make the distinction between a tester and a test engineer. I realize that it exists, but I am asking us to blur the line.

    Thanks again!

    Liked by 2 people

Comments are closed.