There is a lot of talk about everyone should learn how to code. It is the ‘end’ for any software activity which does not involve coding. While I don’t feel this to be true, but nonetheless I strongly feel testers should be ‘technical’. In this post I’d like to distinguish what is the meaning of ‘being technical’ and being a programmer.
Being technical vs knowing to code
A technical person, in the general sense would be someone who knows how the software is working, how to find issues and trouble shoot any problems they see. Being able to code is a subset needed to develop this skill set, and certainly not the only skill needed to be technical. As far as traditional testers go I feel this is a very important distinction.
There are also other ‘personality’ aspects about being technical and certainly some of them hold very important insights, in this post I am focused more on automation vs being technical rather than going into the depth of characteristics of being technical.
Automation, a means to an end
Traditional testers, when thinking of switching to the next career move, the first thing they start off with is leaning automation. In there too, starting from installing IntelliJ and learning Java for selenium, which is the worst place to start for a newbie programmer. This approach sets people to fail, I call a ‘planned failure’. Apart from this being a bad approach, I feel it’s the wrong one too.
Automation is not done for the sake of it, it’s a means to an end. That end is testing the software thoroughly and efficiently as possible. Automation is a fraction of the effort needed to reach there, more important is ‘being technical’. An understanding of how the application works behind the scene. Being able to test the AUT at different levels of the technology stack using different tools at each layer.
There are automation engineers who are reasonable at coding, but cannot be classified as ‘technical’. They don’t know how a web architecture works and lots of other things a technical person should know. It would be more beneficial to know what to automate first, i.e. being technical and go under the hood to identify what areas need to be tested and how, then start automating or ask someone to automate portions of it. Case in point, being ‘technical’ is more important than learning automation right off the bat.
Being technical – Understanding software architecture
The most important point for me being classified as technical is to understand how different pieces of the software work generating the results you see on the screen. A person should know how does the data flow from entering a value in a field till the expected result shown back on the screen. Role played by tools, libraries and frameworks at different levels in the technology stack and how they communicate with one another. Apparently, this might seem a daunting task (if you have some knowledge of how the web works), but the reality is it’s easy to learn and is not as complicated as it might seem.
Being technical – Testing tools
Once you know what’s going on behind the scene, next step is to learn what tools are needed to test at different levels. On the UI you can use developer tools for a lot of things, tracking performance, testing change in data, verifying styling, tests around cookies and sessions. Other tools for multi browser testing and running on different versions.
Next would be the service level. Understanding of how APIs work, some tools to test your application’s API like PostMan. These videos go through the basics of HTTP requests and responses. Tests here can speed up the testing process and allow for a lot more coverage. This is a great place to dissect the AUT, you can have integration tests (spanning over multiple modules) or relatively localized tests (pertaining to specific modules only). All of this however would depend on your product’s architecture.
At the DB level know how to find out which tables are used for saving which data pieces. Knowing how to query them and fetch any needed data. It’s not necessary if a piece of data was saved and retried properly at the UI all is well in the DB. For instance, the character length is wider at the UI while the DB column does not hold that many characters will cause problems.
Being technical – Basics of how programming works
Everyone has done programming of some degree. You might not call programming, but certainly it includes thinking of an algorithm to solve a problem. Programming can be understood as a combination of ‘Giving instructions to a machine to perform a task’ plus ‘a specific language’ in which the instructions are written. The ‘syntax’ of the language changes, but the essence of all languages remains quite the same. Because the method of giving instructions to a machine are in a broader sense similar.
An understanding of how code is written and familiarity with any one basic programming language would also get you started. For reading code written in python, you don’t have to be a python expert (specially in Python’s case by the way) but some idea of loops, conditions and functions would enable you to understand what’s going on for the most part.
Being technical – Disclaimer
By no means am I saying learning to program is not important. All I’m saying is you don’t have to be an expert programmer before you can classify yourself as reasonably technical. By knowing the fundamentals, you can understand the gist of what’s going on and be able to test the code for basic conditions.
Certificate for being technical
It’s human nature to look for someone else to recognize them, to tell them you know this before we ourselves are ready to accept we have a skill. To be technical, you don’t need someone to ‘certify’ you that you know what you are doing. Present your work in the world in such a way that shows you know what you are talking about, and that’s all that matters.
This is a long subject and should be covered in a separate post, to read / listen more on the subject follow Seth Godin, there is a lot of content on YouTube from him as well on this topic.
Learning to get technical
I’d start from learning how software works. Learn how web applications work, the front end, back end, database layers work. What is a technology stack, the widely used technology stacks in the industry? At each level, what tools you can use and how to use them.
Best resources as a one stop shop I found Lynda.com and Pluralsight.com to be the best. Lynda would serve better when learning these topics on a higher level without diving deep into the code. PluralSight I find is more in depth and is more about how to program. Start from Lynda, learn the concepts. If you feel you want to dig deep, you can try Pluralsight or find a good in-depth course from other platforms like Udemy and follow up there.
For testing thought leaders, I strongly feel there should be courses helping testers to be more technical. I’ll try to do some, if anyone is interested to pitch in with me, drop me a message!
Very well said sir… I completely agree with you.
I don’t consider myself to be a thought leader but I would like to help you out in this initiative. Do let me know if you need any help. I have been in the testing industry for 10+ years and would be able to provide some inputs definitely.
Thank you Ravi.
Hi Ali, Indeed a great initiative. .. I went through the same cycle and later kept questioning myself about programming and being tech… Let me know and I will be more than happy to support