From the past few years whenever I travel, I usually try to meet people I know from social media if I get a chance. This year while attending the Test Leadership conference I did the same and dropped a message on the social channels.
Vignesh is one of the people who has been in touch and sharing ideas on testing and automation. Last year when I was in Philly we decided to meet, somehow our schedules got in the way. This time Vignesh again reached out and was adamant to meet.
I was flying out on a Saturday and the only time he could make it was Friday evening. What I learned later, he was based in Virgina and wanted to meet me in New York! The best he could do was around mid-night, and I had to leave for the airport early morning for my flight back to Dubai. It would have been very late for me, but he was so passionate to meet I just couldn’t refuse him.
It was 1 AM when I got his message he had arrived in the Hotel lobby. It was such a treat to talk with him and see the passion to learn gleaming out of every sentence he spoke. We discussed around testing careers and what skills to focus on to advance as a tester.
Fundamentals of the next generation tester
I’ll try to summarize the main areas I feel a tester should focus on, the details of it will have to be a separate (and important) article I’ll have to pick up later.
I hope he learned something from me, here is what I learned from him:
Invest in yourself, and the best way is to learn in person.
We finished the conversation around 3 AM, after which Vignesh was to take the next bus back to Virginia! (I thought my 14 hours flight was bad). Before he left, here are the two of us (with me in my PJs) happy to have spent time learning and sharing:
The secret sauce to enhancing your career
After all the self helpery books and my experience over the years, the most important ingredient which people often miss out on is consistent hard work. Most of us keep searching for the silver bullet to jump to success without putting in the hours, which does not exist. While surely there are many other factors which contribute to moving forward in ones career,
There is no substitute for hard work
So, to all those who want to move forward, putting in the hours to hone your skills and seeking the best ways to do it is most important. Nothing else will work unless this fundamental is there.
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 videosgo 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!