The context of this blogpost is captured here. In short, this is a part of Q & A i did with Women Testers website recently on the topic of careers and beyond. The questions were asked mostly by people who were at the early stages of their career. The series can be located at: https://www.womentesters.com/q-and-a-with-anuj-part-1/
[Anuj] Let me first get the question right before getting to the answer.
To me, the phrase ‘Technical tester’ is an oxymoron.
In today’s day and age, everyone associated with software business are supposed to be sufficiently technical.
In my own career, I have interacted with professionals from spectrum of roles and functions. As example, one may argue that salespeople can escape with minimal technical skills. But the best sales people I have seen are the ones who are technically very articulate (among other skills)) and can strike rich conversations with customers. This, for a tester it’s a given that she has to be technically deep in the chosen area of expertise and technically broad in other related areas.
2. Second thing that I would like to correct in the question is the association of word ‘technical’ with only programming skills. Before you get me wrong, programming skills are without doubt important but they just aren’t the “only” technical skills out there. Right from your product architecture, APIs, underlying operating system, interactions with external systems, security, performance- there are innumerable ways to slice and dice technical skills. So I would encourage testers to have a holistic view of skills rather than looking at it from a narrow lens.
With this context established, I really see the problem expressed in this question as being mindset challenge and learning or learnability challenge. Allow me to explain it a bit:
A cursory glance at the way our society operates will reveal that as a humans, we are experts at categorizing ourselves in as many granular ways as possible. An example, we subconsciously categorize people based on city they come from, the way they speak, based on religion and so many ways. This thinking is just the byproduct of society we live in and I am not trying to be judgemental about it. It is what it is.
But professionally the problem happens when we start applying such thinking at work. We use the society imposed template to look at the jobs and start categorizing them. We start thinking I am a manual tester and programming is developers responsibility or managers job is to encourage the team unless she does it, I won’t show initiative. This is the mindset aspect of question that I was talking about. If we apply this template to our jobs, we give away control of situations to the forces beyond us. So the first thing to do to become a better at anything you want to do (in this case, programming) is to instill belief in self that it is my responsibility to become a better at a desired skill, it is my job, I am not doing a favor on myself by learning- my future paycheck depends upon how I learn. Would strongly urge to shun categorization mindset.
Secondly, I talked about it being a learnability challenge. What I mean by that it most of us want to learn skills but we don’t see “learning how to learn’ as a skill. That ‘i want to learn programming language’ is a skill based learning mindset. If you twist this question to ‘How quickly can I become a world class programmer” it will invariably force you to think through the learning methods you should apply to get to the goal in minimal possible time.
Most people like to learn via books, via internet sites, joining classes and that is fine. But the problem becomes if you continue leveraging just these means but remain underinvested in evolving other learning methods that can give you better investment from time. 70:20:10 model of learning addresses this challenge well. It simply states that 10% of all learning happens via formal education like classes, books, online tutorials. 30% of learning happens via modes called as social learning, which includes mentoring, spending active time with people who are great at what you aspire to become and 70% of learning happens on the job, when we work on live projects, take on challenges head on while working under time pressures etc.
The irony is that more often we spend 80% of time learning via formal education means, which really impacts 10% of learning surface. So there is a need to look at learning from fresh lens and invert the way we think about it.
Let me summarize the answer in 5 actionable tweets:
1. As a tester, you are expected to be technical. There is no ambiguity about it.
2. Being technical, doesn’t just include programming but a wide variety of skills based on context of your project/area.
3. Shun the categorization mindset. It is solely your responsibility to get better at your chosen area of expertise. Choose to stay in control of your learning.
4. Don’t just narrowly focus on what you wish to learn. Invest your time in learning how to learn effectively.
5. Don’t just learn from books, online/face to face trainings. Get a mentor. Spend ample time learning from experts. Pick a live project that is much beyond your current skills and persevere to execute it till the end.
Q: As a tester without dev/coding skills, how to become a technical tester with programming skills?
To me, the phrase ‘Technical tester’ is an oxymoron.
In today’s day and age, everyone associated with software business are supposed to be sufficiently technical.
In my own career, I have interacted with professionals from spectrum of roles and functions. As example, one may argue that salespeople can escape with minimal technical skills. But the best sales people I have seen are the ones who are technically very articulate (among other skills)) and can strike rich conversations with customers. This, for a tester it’s a given that she has to be technically deep in the chosen area of expertise and technically broad in other related areas.
2. Second thing that I would like to correct in the question is the association of word ‘technical’ with only programming skills. Before you get me wrong, programming skills are without doubt important but they just aren’t the “only” technical skills out there. Right from your product architecture, APIs, underlying operating system, interactions with external systems, security, performance- there are innumerable ways to slice and dice technical skills. So I would encourage testers to have a holistic view of skills rather than looking at it from a narrow lens.
With this context established, I really see the problem expressed in this question as being mindset challenge and learning or learnability challenge. Allow me to explain it a bit:
A cursory glance at the way our society operates will reveal that as a humans, we are experts at categorizing ourselves in as many granular ways as possible. An example, we subconsciously categorize people based on city they come from, the way they speak, based on religion and so many ways. This thinking is just the byproduct of society we live in and I am not trying to be judgemental about it. It is what it is.
But professionally the problem happens when we start applying such thinking at work. We use the society imposed template to look at the jobs and start categorizing them. We start thinking I am a manual tester and programming is developers responsibility or managers job is to encourage the team unless she does it, I won’t show initiative. This is the mindset aspect of question that I was talking about. If we apply this template to our jobs, we give away control of situations to the forces beyond us. So the first thing to do to become a better at anything you want to do (in this case, programming) is to instill belief in self that it is my responsibility to become a better at a desired skill, it is my job, I am not doing a favor on myself by learning- my future paycheck depends upon how I learn. Would strongly urge to shun categorization mindset.
Secondly, I talked about it being a learnability challenge. What I mean by that it most of us want to learn skills but we don’t see “learning how to learn’ as a skill. That ‘i want to learn programming language’ is a skill based learning mindset. If you twist this question to ‘How quickly can I become a world class programmer” it will invariably force you to think through the learning methods you should apply to get to the goal in minimal possible time.
Most people like to learn via books, via internet sites, joining classes and that is fine. But the problem becomes if you continue leveraging just these means but remain underinvested in evolving other learning methods that can give you better investment from time. 70:20:10 model of learning addresses this challenge well. It simply states that 10% of all learning happens via formal education like classes, books, online tutorials. 30% of learning happens via modes called as social learning, which includes mentoring, spending active time with people who are great at what you aspire to become and 70% of learning happens on the job, when we work on live projects, take on challenges head on while working under time pressures etc.
The irony is that more often we spend 80% of time learning via formal education means, which really impacts 10% of learning surface. So there is a need to look at learning from fresh lens and invert the way we think about it.
Let me summarize the answer in 5 actionable tweets:
1. As a tester, you are expected to be technical. There is no ambiguity about it.
2. Being technical, doesn’t just include programming but a wide variety of skills based on context of your project/area.
3. Shun the categorization mindset. It is solely your responsibility to get better at your chosen area of expertise. Choose to stay in control of your learning.
4. Don’t just narrowly focus on what you wish to learn. Invest your time in learning how to learn effectively.
5. Don’t just learn from books, online/face to face trainings. Get a mentor. Spend ample time learning from experts. Pick a live project that is much beyond your current skills and persevere to execute it till the end.
No comments:
Post a Comment