Do software testers need to write code? Probably no.
Do software testers should learn to code? In my opinion, Yes – we must.
The testing community has discussed this issue many times. Many people argue that testers do not need to write code, and I have no problem with that. In my day-to-day job, I spend less than 20% of my time in writing code – so it is not important.
In teams I usually work with, developers will happily write automated tests at every layer, including, unit, integration, acceptance, GUI, performance – everything. I often focus on activities such as exploratory testing, clarifying stories/ requirements with business analysts/product owners, discussing what should be tested and how best it can be tested with developers, planning/performing end-to-end or system testing, coordinating releases in various environments and prod, preparing test data and many such activities.
Writing code is a small part of my job.
So yes, I agree that testers do not need to write code. However, I get disturbed with the view that testers do not need to learn to code. In my opinion, testers must learn to code. No excuses.
There are many benefits of learning to code. Some of the advantages I have realised are –
- Ability to code makes me comfortable in owning/preparing test environments. I am not scared of the technology stack and feel confident that I can deal with it. I can find what problems there might be, research, ask for help and often resolve issues quickly. I can easily dig deeper and am confident in dealing with things like Web Servers, DBs, Message queues, OSes and so on. Also, when needed I can write (or suggest) scripts to maintain, monitor, prepare test environments.
- It’s easier to drive testability if I am comfortable in coding. I do not need to write code; I just need to have fairly good understanding of what might make the underlying code more testable. I can discuss with developers why it might be a good idea to have test-only end-points, hooks in the system, test-only configurations and I can also appreciate limitations dev might have in implementing some of them.
- I can clearly see boundaries and layers of underlying systems. This insight helps me in avoiding duplication of test efforts. It also gives me opportunity to focus on things which are important to test from the system’s point of view.
- Ability to code gives me a better understanding of release process. I can appreciate different branching strategies; I can see the importance of continuous integration and can discuss merits and risks of continuous deployments. I find it easier to own continuous integration for automated testing.
- I can appreciate and understand complexities of development better. I find it easier to spot risks, find problems in the architecture, speak the language of developers, understand their design decisions and able to contribute meaningfully to the technical discussions.
Apart from these, in my opinion, we need to learn to code because the market demands it. New team structures demand it. Way we develop software is changing, and we need to keep it up with these changes to remain relevant.
So there are many reasons for learning to code. Still, I fail to understand the reservation some testers have for learning to code. In my opinion, skilled testers should build their tools (And before you jump to the conclusion for the word tool – checklists, mnemonics, etc. are all tools) and ability to read, understand and write code when needed could be a very useful tool for testers.
Skilled testing and learning to code is not mutually exclusive. In my opinion, the ability to code is an important skill for testers. My experience is limited, but most of the good testers I have worked with were comfortable in writing code. They didn’t have to write code, but nevertheless, they were comfortable and used their ability to code to become better and more effective at what they were doing.
So before I rant more, let me share a bit of background on the reason for writing this post.
I read this blog post from Rob Lambert and followed the discussion on Twitter. There were usual arguments on it is not important to learn to code, and I thought what if we change the question? What if instead of showing the benefits of learning to code, we ask a different question to understand why some people are not learning to code? Are they not learning because of opportunity cost, inertia, lack of interest, fear or something else?
I posted this question on the twitter, and some of the reasons I received in response are
- Opportunity cost
- Testing and coding are different.
Let’s analyse these reasons.
Opportunity cost – Learning to code takes time
I agree that learning to code takes time. However, if that’s the only reason, it’s fine. This argument gives an impression that there is no disagreement on the importance of learning to code. However, there are other things you need to learn, get better at and coding is not important enough right now.
If that’s the case, I suggest you make a list of things you need to learn/ are learning explicit (Don’t need to share with others if you are not comfortable – explicit could mean just write down your learning goals). This will help you
Analyse what you are gaining by learning a particular skill, how it can help your team and how it might assist you in progressing your career.
If you have plenty of things to learn and coding is on the list, and you have taken a conscious decision to learn other things before coding – It’s fine. No problem with that – just make this decision consciously and ensure that you are learning other things regularly. So long it’s on the list, and you are striking off items before it – it’s fine.
Lack of interest – no interest in coding
I have no problem with this argument as well. Provided, you have learnt how to code and did not want to write code.
Let me repeat;
It’s okay to not write any code, but it’s not okay to not learn to write the code.
I know how to code, but I do not want to do it is different from I don’t know how to code and have no interest in learning to code. It’s fine not to have interest, but don’t use this argument if you have never tried to code and learnt how to code. Give it an honest try – there are plenty of avenues where you can learn.
Also, learning to code doesn’t mean that you’ll have to write code. By learning to code, you probably understand a bit more about decomposing problems, architectures, choices developers are making and all of these things can affect testing.
Different skills – Testing and coding are different
Yes, of course, they are different.
I do not expect testers to write good code and programmers to be able to test as efficiently as a skilled tester would test. However, I believe that
We are not in the business of testing software. We are in the business of delivering software.
It’s a complicated thing, and I find it useful to have a basic understanding of everything that is involved in delivering the software. Delivering software includes everything – from the requirement to development, to deployment and customer support – everything.
I have a keen interest in testing, and that is my focus area. However, understanding how software is developed and delivered helps me get better at testing.
I see code, architecture and design principles as fundamental blocks for delivering software. I find it useful to understand architecture, discuss design decisions, have insight on coverage at various level and this knowledge often guides/inform my testing. This knowledge becomes an important part of my context.
I am certainly aware of the risks of writing bad code and how it can impact testing. I am not advocating that testers become generalists and become an average tester and bad programmer.
What I am suggesting is – please do not consider coding skills and testing skills as mutually exclusive. Ability to code is an important skill for a tester. Make an effort to learn it.
Would be nice to get your views on this. What are the benefits of learning to code? What might be other legitimate reasons for testers not to code which I am not aware of?