This is a guest posting by Simon Knight. Simon Knight works with teams of all shapes and sizes as a test lead, manager & facilitator, helping to deliver great software by building quality into every stage of the development process.
Sometimes, I like to think of my teammates as a kind of band of adventuring heroes. Usually, I don’t mention this to them, in case they start looking at me funny. But when I gaze across the room at the product owner, if I squint and use my imagination a bit, I can see a bit of Elf in her. Probably she’s handy with a bow and arrow. If she was a World of Warcraft character, I reckon she’d be a Hunter class; great at long range thinking and decision making.
Sitting next to me I have a Warrior class programmer. Master of the weapons of his trade. Capable of slaying a tricky line of code with a single blow. Myself I think of more as a kind of Shaman. I get to call on elemental powers, unleashing the primordial forces of skilled testing to support the team and help them deliver a great product.
Mostly I’m happy enough doing my thing. I’ve levelled up quite a bit. My spells have power and the team appreciate them. Every so often though, I’ll watch my warrior buddy slicing and dicing code and think, it would be great to carve a few lines myself. I’m not going to be a full time code warrior, so I don’t need a broadsword or a battle-axe, or anything heavyweight. My weapon of choice probably wouldn’t be an Oathkeeper. I’d prefer something with a bit more Sting.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Context Is King
There’s some solid arguments for learning a bit of programming swordplay. Being able to slice beneath the surface of the application code means you can better understand what’s going wrong, and why. Your bug reports will be better informed and the additional information you provide to developers when raising defects means shorter feedback loops.
Of course the software you’re working with comes in many shapes and sizes. And you don’t have to interact with it in the way the developers intended. If you’re working on a web application for example, operating the software while keeping a browser dev tools window open will provide you with a view of the client-side code and resources. Running your software through a proxy can help you to see what requests are being sent and received. Being alert to application behaviour by way of a logging or monitoring tool can help you see even further down the stack.
The nature of the software your team is working on is ultimately going to determine what tools (or weapons) will serve you best. Testing a web site is going to be very different to testing a native application, or a piece of embedded software. There’s a common thread though. Whatever kind of software you’re testing, the engine beneath it, the thing that makes it all hang together, is code. The software behaves the way it does because that’s the way the developers have programmed it to.
So given that, as a software tester, your job is to test software that’s driven by code – it makes sense to learn how to understand how code works, right? Well, you’d think. But it turns out, there’s some debate about this very subject. Not everyone agrees that testers should learn to write code.
What’s All The Controversy?
If you follow some of the testing voices by way of their blogs and other social media, you may have come across arguments against learning to code like these:
- Being able to code will make you think more like a computer and less like a person.
- If you know how to code you’ll spend more time doing that and less time testing.
- Learning to code comes at the expense of learning other, equally or more important skills.
- Developers are better at programming anyway. Testers should focus on testing and let the developers write the code.
You’ll also see arguments in favour of learning to code, like these:
- You’ll be better able to speak the language of your developers.
- You’ll have a better understanding of the complexities and accompanying risks of development.
- You’ll empathise with your teammates better when you understand the coding problems they face on a daily basis.
With all of this controversy around the subject, you could be forgiven for wanting to sit on the fence. But there’s more:
Anyone who is serious about a career in testing would do well to pick up at least one programming language. – Elisabeth Hendrickson
Back in 2010 Elisabeth Hendrickson carried out some market research and observed that 80% of the advertised testing roles they looked at seemed to require some kind of programming experience.
More recently, Rob Lambert speaking as a hiring manager notes that although there might once have been an argument for less technical testers who focused more on the big picture business scenarios, there are now plenty of testers who can write compelling test scenarios and develop the code to execute them as checks too.
It’s no longer enough to be a tester who doesn’t code, because when you apply for a job you may be up against a tester similar to you who can code. – Rob Lambert
If we take those last two points as arguably the most compelling reasons for learning a programming language or two, you’d think that life would become a bit clearer. You just need to make a decision about what programming language to learn and get on with it, right?
Wrong. Turns out, even that’s not straightforward.
What Does Learning To Code Mean Anyway?
Figuring out where to start learning anything can be tough. There’s so many choices! Should you go to college? Do an online course? Read some blog posts? Buy a book?
Learning a programming language can be particularly difficult. Before you start studying, how do you even know which language to choose? Figuring out answers to the questions below may help to narrow down your options:
What kind of work are you doing?
The software you test and the platforms it needs to work on may have a bearing on the kind of programming language it will be useful for you to know. If you’re working mostly on the client side of a web application, learning some Javascript might be more useful than learning some Java.
What does your code need to do?
Having a specific purpose or task that your code will be used for, in addition to being a great motivational tool for learning it in the first place, can be used to steer your decision about which language to actually learn. If you just need to create some data, a scripting language or some variety of SQL may be sufficient. If you need to develop a tool that’s intended to be a bit longer term, something more heavyweight like C# or Java may be required.
Where will your code be run?
Does your code need to work in a browser? On the server? On a desktop? In Windows, OS X and Linux? On a mobile device? The platform on which your code needs to be developed and run (or run against) should be a consideration.
What is everyone else using?
If you’re working on a team or project and everyone else is using C#, developing your scripts and tools in Ruby may not be the best idea. In addition to not wanting to upset folk, you want to take advantage of all of the experience and knowledge that’s around you, right? Find out what the preferred language of your colleagues is, and why. Then ask them for their advice and support in getting started with that language. Most often, they’ll be happy to provide it.
What skills is the market looking for?
Scanning job advertisements will provide a good indication of what skills are hot in the marketplace right now (as Elisabeth demonstrated back in 2010). You need to balance the ebb and flow of fashionable skills with longer term trends though.
Learning to Program
If you’ve chosen a programming language to get started with, you’ve cleared the first hurdle. It’s time to start developing those skills! The strategies below will help you on your way.
Talk to someone else who writes code
You’re probably already in one of the best places to learn programming; amongst developers! Go out of your way to talk to them and get them sharing their knowledge. Ask them to show you how their code works. Even better – sit with them as it’s being done. This way, you can add value by sharing your testing ideas while the code is still being written.
Look for examples of the same code in lots of languages
If you decide to read a book or some blog posts that provide typical examples, don’t just read code for the language you’ve decided to learn. Look at example code for other languages as well. Try to understand both the differences and the similarities so you can start to understand underlying patterns and principles.
Write some of your own code
Writing your own code will add depth to your understanding that simply can’t be achieved just by reading somebody else’s. And programming isn’t just about writing the code in any event. You have to setup your environment, familiarise yourself with the tools and carry out various other tasks along the way. There’s really no substitute for learning by actually doing the work.
Make changes and test them
Once you’ve gotten started with actually working through some examples, and hopefully got them working, start to make some changes. Apply your exploratory testing skills. Formulate a hypothesis, make a small adjustment, then observe the result. Look for ways to improve and optimise your code.
Learn to understand the compiler and debug your code
While you make changes you’ll probably experience some compilation or execution failures. The console will report an error of some kind, but do you understand what the error message means? Learning to search for reports of the same problem will be invaluable at this stage of your learning curve. Consider adding some logging to your code so that problems can be traced and pinpointed more accurately.
Look for things to do with your code
As your confidence grows and useful examples to learn from start to thin out, it’s time to start looking for ways to implement your learning at work. Mechanical activities that have to be repeated often are great candidates for code or scripted execution. But what about smaller, more ad-hoc tasks like data creation, extraction or manipulation? Try to think about ways you could carry out day-to-day tasks by writing simple scripts.
Store, share and re-use your code
As your portfolio of scripts and code grows, you’ll need somewhere to keep it all so you can refer to and re-use it. If you haven’t already done so, investigate some version control tools and code repositories. Git and Github are very popular (though other options are of course available) and Github makes it very easy to store and share your code with others.
Read someone else’s code
If you’re already working on a software project, why not download the source code and read through it? Many developers try to follow a test-driven approach to development, so unit tests are a great place to start. Some development tools will also let you step through the code as it’s being executed, which is a great way to see how it works in action.
Work on code somebody else wrote
Open source projects are a good way to start putting your new found skills to the test. Some of the software you use on a day to day basis is probably open source. Next time you use a tool, think about ways in which it might be improved? Join the mailing list for the development group or search the web for features under development and bugs that have been logged. Try to fix a problem in the source code or find some other way to contribute.
Practice, practice, practice!
If you want to get really good then you’ve got to keep putting in the work. It may not take ten thousand hours, but you should certainly expect to put in a significant amount of effort to become anything near competent. And even then, practice isn’t necessarily the same thing as experience. Professional developers solve all kinds of engineering problems on a daily basis. If you’re serious about learning to program, try to get some experience with production code. In these days of cross-functional teams, it shouldn’t be too hard.
Is Learning to Program Really Worth All The Effort?
There are many routes you could take towards becoming a highly skilled tester who is able to add significant value to the projects and teams on which you work. Leveling up your coding swordplay is just one of them. And one will that require significant time and effort.
So is it really worth it? Some people say that just learning to read code is enough.
“I advocate learning to read code over coding. Coding well can take a significant investment in time and practice.” – Alan Parkinson
Others argue that learning about programming (James Bach) or learning about IT (Patrick Prill) may be more valuable. These are all perfectly valid arguments, but learning about programming and IT is analogous to learning about swordplay and hand-to-hand combat.
Learning to read code would be like learning to read and predict an opponents movements in a fight. Useful skills to be sure. But not quite the same thing as being able to fight back.
The way that you learn how to handle a sword is by picking one up. Feeling the weight. Learning to swing, thrust and parry. Sparring against a real, live opponent once you’ve learned some moves. Learning to program is the same.
Reading a book or watching a few training video’s really won’t cut it. You need to sit at the keyboard and practice your moves, over and over. As you do so, your programming skills will start to emerge, and your understanding of what professional development looks like below the surface will grow.
This guide should get you started, but if you have some strategies that you’ve found particularly helpful in levelling up your programming skills, we’d love to hear about them in the comments section below.
PS: Have you found this article useful? We will have more relevant testing & QA related articles soon on topics like building a great testing team, improving your testing career or leveling up your testing skills. Make sure to subscribe below via email and follow-us on Twitter!
