Tag Archives: Anuj Magazine

Q and A with Anuj Magazine – Part 1

We asked Anuj Magazine a mixed bag of questions about testing, career and skills required for a tester. Here shared in this quest for endless testing knowledge is his deep understanding of this science and brief answers.

Q) As a tester without dev/coding skills, how to become a technical tester with programming skills?

A) 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) If I join as a SDET today, where should I see myself after 10 years?

A) In the next 10 years, you should see yourself as a CEO of an organization making immense impact on the company, employees and society.
What distinguishes us humans from other living species in the power to dream. Why waste this power by choosing to dream small. One promise we should make to ourselves is that whenever we think of future, it is bigger, bolder and better, much better than today.

There is one more perspective I would like to offer on this subject. When we think of ten year career horizons, we generally tend to think growing vertically i.e. if I am an SDET now, I would be Senior SDET in 2 years, then Staff SDET and so on. There is nothing wrong in thinking vertically except for the fact that vertical plans for careers tend to be self-limiting. What I mean by self-limiting is that designations trap you into thinking that reaching next level is the only goal you should have even if you are capable and are performing at much higher levels.
If you consider any industry leader you admire and look at their career profiles, I bet they wouldn’t have reached where they have reached by just following organization’s laid down career frameworks. They may have followed that a bit but more than that they would traversed horizontally and chartered their own unique paths.

In summary:
1. You are capable of reaching at unprecedented heights in your career in 10 years time provided you choose to aim higher at the first step.
2. Follow career paths laid down by organizations as a guidance at best but not the only way to grow. Successful people create their own paths however difficult it may be.
3. Like everything around you, within next 10 years the SDET role itself would have undergone transformation for good or bad. It’s best to have a pulse of what’s happening around you, have informed opinion about the future and change course as needed.

Q) For Women Testers, do you advice moving into technical role or management role as she moves forward in her career ?

A) Let me start by sharing 2 stories with you:

I recently ran Singapore full marathon. It was a gruelling course of 42.195 km with a very hot and humid conditions. In such a course, one seeks inspiration from fellow runners to keep at course and continue going. Many a times during the run, I looked up to female runners who were running better and strongly than I was.

A couple of years back a wrote this article: “What testers can learn from my wife” in Women testers website. In this story, I narrate how my wife inspires me professionally everyday. Being a woman in an extremely male dominated automobile industry, she managed to successfully carve a niche for herself, despite many odds facing her. She took-up and excelled in both management and technical path.

What I am trying to allude towards is that I don’t believe that gender should even be a factor in deciding or limiting yourself to choose any career path of your chose. Of course, there may be challenges in certain paths, but isn’t that true for anything worth doing in life.

One heuristic you can try choosing between technical and management role: If you like being with yourself more, try technical path. If you like being with people more, try management path. However, this heuristics is only valid for early stages in the career. As one grows towards more senior roles, even the technical roles need more and more social skills and management/leadership roles need more and more technical skills.

In summary, no career path is written in stone. Following 4 steps can help you reach your potential.

1.identify your strengths,

2.show appetite for experimentation,

3.if things don’t go as per your liking don’t hesitate to change course.

4.go to step#1.

https://www.womentesters.com/what-testers-can-learn-from-my-wife/

I don’t see career paths from the lens of gender.

In my world view women can excel in any chosen path- technical or management and so can men.

What Testers can Learn from My Wife

Let me start by guessing what you might be thinking looking at the title. Some guesses-
1. This must be an emotional piece from someone who adore his better half.
2. This must be a sort of self/family achievements boasting exercise.
3. This must be something about a next generation test innovation.

If you are thinking on the above lines then i only have one word for you- Sorry, your assumptions here are misplaced. It might take me rest of the article to explain about my stand here but let me clear some things upfront-

1. My wife is not a software tester.
2. In fact, her job profile has nothing remotely to do with Information Technology.
3. She is an engineer by qualification and professional experience.

As a family, we have been brought-up in a culture that values humility to the core. As a result of this foundational nature, we are probably low key about the way we are and about our humble achievements, if any. Being low key usually have a negative connotation to it especially in the cultures and sub-cultures that value extroversion. But to me, being low key does not mean being anti-social as we are sufficiently social and thriving in the space that we operate in.

With this background, i can say that what i am attempting to share here is probably something that does not come very naturally to me. But in the spirit of sharing for the betterment of our profession, i thought it is a risk worth taking. So my words my stumble, grammar may get shaky, the full stops may seem too far away but still here i attempt to narrate the lessons that i learned from my wife that helped me become a better professional.

A bit more about my wife:
Being engrossed in the everyday challenges of Information Technology profession, we sometimes get too blinded in our world. So much so that we don’t recognize that any other profession or job that can be as challenging, if not more. If i just say that my wife is in automobile engineering profession, it may not give perspective on what she actually does- so let me narrate a bit more.
1. A very mention of the word “automobile” should give a sense that it’s a profession that is dominated by a certain gender. No prizes for guessing which one. One could argue that even IT is dominated by male bastion, which i don’t deny. But difference lies in the extent. If, for example, IT has male/female ratio as say 3/10- take automobile world as 0.25/10 or even less.
2. Her job role is at managerial level and she belongs to a core engineering role, by which i mean- as a part of her role she knows each and every part of two-wheeler (her area of expertise). Every now and then, she gets to open each and every part of a two-wheeler and assemble it back. As a part of Quality role that she played, she knows quality assessment and parameters of each and every part involved in making a bike. As a part of her Service engineering profile, she gets to train managers, engineers to workshop workers on the technical nuances of her area of work. And much more.
3. She thoroughly enjoys her job and is passionate about it.

Professional lessons that i learned from her:
With this background, i will attempt to share some worthy lessons that i imbibed from her.

1. Be hands-on not because of your position but despite of your position
Few days back, my wife told me that she needs to go to work wearing the sports shoes. No, they didn’t have any sports event in the organization but on the contrary, it was the strike period. For those unfamiliar, strike happens in manufacturing plant when the workers usually have some unmet demands and they decide to abandon work. So why did she need sports shoes? On a lighter note, it was not to “run” away from work but rather run towards it. Let me explain- Given that it was a strike, the management had requested people from the organization to help with meeting production targets. She willingly volunteered for the same and was required to work and deliver Compressor internal assembly. She needed shoes (than the usual sandals) as a protection towards accidental oil spillage or heavy parts getting dropped.

Crises situations are not new to Software testing profession. We are faced with many uncertain situations during the life cycle of a release, including but not limited to- build breakages, late arrival of requirements, blocker bugs, and new changes at the end of the release, people attrition, and possibly many more. That truly is our world in Software testing. From the above incident that i narrated, the core question for me is- How often do we see Managers and Executives contribute hands-on when the crisis situation arises? Of course, there is guidance, words of encouragement and motivation from higher-ups but hands- on involvement?

I am sure we have seen some instances but does it happen often?
So, the core lesson she taught me is- Be proud to be hands- on, not because of your position but despite it.

2. Work for your passion irrespective of not getting the credit

I am sure most of the current generation Software testers are passionate about what they do. As i have experienced in my career, the extent of our passion towards our craft really gets tested at many times. One of the crucial such phase is when we go through a lean phase in our career.

The work culture in automobile profession is quite different from that in software industry. It’s a task oriented culture to the core. It means that if you do the task, then usually there is no response from your manager but if by any chance, you miss to do that you were asked to, then all hell can break loose. Of course, it is a person-dependent thing but higher- ups in that culture are quick to spot when you are wrong (even if you are really not) than really take efforts to appreciate the right deeds of an employee. Usually, the rebuke for mistakes is public deploying the choicest words. My wife usually a lone female in such meetings have been subject to uncomfortable situations mostly for no fault or mistake of hers as she is usually always ready with data- bound explanations. The bigger point here is how one gathers the motivation to continue one’s job if you are subjected to such situations almost daily, either happening to you or your colleagues. This is where I have seen her exhibit tremendous maturity to focus on task (not on people) and deliver great work despite not been given credit and accolades she deserves.

In Software testing world too, there are many difficult situations where our passion gets tested but you would agree that they are largely at a much lesser extent than what i described above.

From her i learnt to respond to unfair situations with the same élan as any other work situation. Treat every day at work as experience. Don’t leave seemingly bad bosses at once, as there is much more fun and fulfillment in winning such people over by your passion, focus and hard-work. And don’t keep bad experiences sulking within you, speak to your close ones, have mentor and routinely clear your mind off the negative thoughts.

3. Get better at job even if it means learning and mastering the local language.
No, the language here does not mean programming language, it’s the one that we use to interact with other human beings. Somehow, the people at the job my wife was doing spoke to each other mostly in the local language of Bangalore i.e. Kannada. Being the only non-Bangalore person, she realized that she will need to adapt to local culture sooner than later. Such adaptation would need her to learn and converse in the local language. With her will and determination, she picked-up the individual words, then small sentences and eventually became fluent in Kannada. From a non-starter in the language to achieving fluency good enough to train the people technically in local language in a matter of few months was nothing short of transformational to me.

Is learning local language important for Software professionals? Whenever i have asked this question to people, the response has always been skewed towards a resounding No. And that’s because people feel that writing and testing code majorly requires us to know English or English-like syntax’s. To me that’s a very narrow way to look at one’s job. Broadly speaking, every job has two aspects to it. The core job itself (development, testing etc.) and the people relationship aspect. Even if we write or test code, the work cannot be accomplished without teaming up with others and in certain cases, without approval of others. Now, one can argue that every organization has a business language and that must be followed to get the business done. There is no problem, in general, with this argument but it misses a larger point about complexity of human relationships. Such relationships, including at work, are never linear -as an example, even though English is a preferred business language, often people feel more connectedness with those who embrace local cultures. I would be missing a point if you are feeling that knowing local language would amount to favoritism, that’s not at all what i mean. But all I am trying to stress is the subtle nuances of human nature and why a seemingly unrelated thing like mastering a local language can enable us to work better than without having that knowledge.

4. Have a child like curiosity towards embracing newness

Newness, in essence means change.In automobile world, which arguably follows sort of fixed production process, newness opportunities may be thought of as limited. But automobiles are also invested a great deal in R&D and that is seen in the capability of organization to come up with new models. New model launches bring in a great sense of anticipation in the organization and for the techies post production, it is an opportunity to explore. That is what i have seen my wife do with almost a childlike questioning, exploration and figuring out each and every detail of what has changed not only at the exterior but also going a step ahead and opening the vehicle up and intricately checking the details.

Software testing profession also sees such situations when the new versions of the software gets released. Often testers deploy the build and observe what has changed. What i have not seen as often is the curiosity to see the code and understand what has changed and design tests. This is what i have learned from my wife’s experiments with the newer models of the vehicles. If you are really a curious software tester, then you shouldn’t be restricting your curiosity to what happens on the exterior but rather go a level down and see how raw code is designed.

5. Thinking out of the box is fine but not at the expense of making the box dirty
Most of the jobs in automobile engineering profession would require following a process to ensure conformity. This is done to ensure that physical parts that millions of automobiles use should behave the same way across. To ensure the sameness of such high-degree, it requires that the process that goes into making the part and later assembling the same is identical, and fool-proof. So while there are part of jobs that deal with R&D, a good chunk of jobs are related to ensuring consistency and less variance, and this is where process orientation is a key virtue. Following the process for certain things is taken as a given expectation.

Coming to Software engineering world, I have seen certain fascination by many people in believing that following a process is not right or something similar. Agreed that a good portion of software engineering requires a Research and Development mindset, but does it mean that all the tasks in testing or development are research based? I guess the answer is- No.

Can the various release phases exist amicably without well- defined entry and exit criterias? Can all the testing be only Exploratory? Does all the test-ware need to be created new (based on Research) always or do we reuse pre-existing test-ware? Does the test-reports not, in some cases, need to be standardized based on stake-holder needs? Doesn’t the role of testing changes based on the phase of release you are in i.e. towards the close to release, the role changes more from finding bugs to confirming there are no ship-critical bugs?

If you look at these and many such instances in software testing world, you would realize that we are talking about situations where we would expect less variations and more conformity. This is exactly what a well-designed process help us achieve. It ensures repeatability of results wherever it is desired and needed. And as you can think now, there are some situations in software testing where this is needed. So before you bash the process, think that processes are here to serve a need. There can be cases where process isn’t designed well and it causes irritation to the impacted people but that doesn’t mean all processes are bad in essence, on the contrary they may be unsuitably designed. The need to embrace innovation (out-of-box thinking) is well understood but processes should also be embraced with same vigor wherever they are needed, otherwise it can potentially impact the project deliverables and overall scalability of the organization.

As I come to the epilogue of this story, I must convey that some advice here may be offbeat, some orthodox but to me, the life really lies between these two extremes. That’s why probably i value my wife’s professional journey. In life one needs reference points to help us walk past difficult phases. To me, she is one of my professional reference points. If i hit a trough, i think of her day-to-day struggles and capability to overcome them and then choosing to celebrate small victories of the day rather than choosing to stay buried in the past.

If you like what i said here and learned even a single thing, i would hugely appreciate if you can drop a note to my wife at [email protected] and express what you felt after reading this (she doesn’t know that I have written this and would surely be surprised).

About the Author

Anuj Magazine is a software testing and general management professional at Citrix Inc. He regularly share his knowledge and experiences as a conference speaker and writes frequently on diverse topics like software testing, management, sports, and handwriting analysis. Anuj tweets at @anujmagazine.