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