There is a lot of talk about everyone should learn how to code. It is the \u2018end’ for any software activity which does not involve coding. While I don\u2019t feel this to be true, but nonetheless I strongly feel testers should be \u2018technical\u2019. In this post I\u2019d like to distinguish what is the meaning of \u2018being technical\u2019 and being a programmer.<\/p>\n

Being technical vs knowing to code<\/h2>\n

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.<\/p>\n

There are also other \u2018personality\u2019 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.<\/p>\n

Automation, a means to an end<\/h2>\n

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 \u2018planned failure\u2019. Apart from this being a bad approach, I feel it\u2019s the wrong one too.<\/p>\n

Automation is not done for the sake of it, it\u2019s 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 \u2018being technical\u2019. 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.<\/p>\n

There are automation engineers who are reasonable at coding, but cannot be classified as \u2018technical\u2019. They don\u2019t 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 \u2018technical\u2019 is more important than learning automation right off the bat.<\/p>\n

Being technical \u2013 Understanding software architecture<\/h2>\n

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\u2019s easy to learn and is not as complicated as it might seem.<\/p>\n

Being technical \u2013 Testing tools<\/h2>\n

Once you know what\u2019s 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.<\/p>\n

Next would be the service level. Understanding of how APIs work, some tools to test your application\u2019s API like PostMan. These videos<\/strong> <\/a>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\u2019s architecture.<\/p>\n

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\u2019s 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.<\/p>\n

Being technical \u2013 Basics of how programming works<\/h2>\n

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 \u2018Giving instructions to a machine to perform a task\u2019 plus \u2018a specific language\u2019 in which the instructions are written. The \u2018syntax\u2019 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.<\/p>\n

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\u2019t have to be a python expert (specially in Python\u2019s case by the way) but some idea of loops, conditions and functions would enable you to understand what\u2019s going on for the most part.<\/p>\n

Being technical \u2013 Disclaimer<\/h2>\n

By no means am I saying learning to program is not important. All I\u2019m saying is you don\u2019t 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\u2019s going on and be able to test the code for basic conditions.<\/p>\n

Certificate for being technical<\/h2>\n

It\u2019s 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\u2019t need someone to \u2018certify\u2019 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\u2019s all that matters.<\/p>\n

This is a long subject and should be covered in a separate post, to read \/ listen more on the subject follow Seth Godin<\/strong><\/a>, there is a lot of content on YouTube from him as well on this topic.<\/p>\n

Learning to get technical<\/h2>\n

I\u2019d 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.<\/p>\n

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.<\/p>\n

For testing thought leaders, I strongly feel there should be courses helping testers to be more technical. I\u2019ll try to do some, if anyone is interested to pitch in with me, drop me a message!<\/p>\n<\/div>

<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":13659,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[53],"tags":[],"yoast_head":"\n