My Unexpected Journey to Becoming a Software Tester (From Entry-level to a Manager)

“You build a Successful Life…A Day at a time…”

My journey as a Software Tester started a bit unexpectedly.

I appeared for the initial interview rounds assuming it to be a Development opportunity. To be honest, like every other Computer Science graduate out there, I was a bit skeptical about going ahead with Testing.

But finally, I decided to give it a try. Only with a hope that my curious nature will help me in this field. 

I couldn’t accept the offer without putting up this question – Will I get an opportunity to switch to Development in case Testing doesn’t interest me? :).

Believe me- I never even got a thought of leaving Testing after that.

When I appeared for the technical round, I wasn’t prepared for anything more than the basic concept of Software Testing. I guess the only thing which took me through was the thought that I am being evaluated logically and not theoretically’.

This was my very first learning in Testing – I understood how we (freshers) were evaluated.

Even today, I use similar techniques while hiring freshers for my team. I check their logic, tenacity and approach to a problem over anything else.

Recommended read => 4 Important Things I Learned in My Journey as a QA Test Manager

I joined Zycus as a QA Trainee and was allocated a product on some third or fourth day. It was one of the biggest (was in concept then) and most ambitious products of the company. After settling down for the initial few weeks, there was no turning back for me.

We started as a QA team of two and soon after few months I was the only one driving the Testing efforts. In the initial 2 – 2.5 years itself I had logged nearly 3000 defects across different categories such as Functional, Performance, Security, UI, Usability, Multilingual, Multi-Tenancy, etc.

For a considerable time before new additions to the Testing team, I was up against a strong 15-16 member development team. Even after the additions, QC:Dev ratio wasn’t very healthy and I can still proudly say it was a successful journey considering all that we tested, delivered and handled.

The important point I want to highlight here is- All this was from an understanding of Testing in practice and not just theory.

I have been in the Software Testing field for almost six years now. It has been an amazing journey with so many different experiences and plenty of fruitful learning.

Presently, I am working as a Senior QA Manager looking after some 5-6 products and modules. But what gives me real joy and happiness is leading a team of 30+ happy and passionate Testers.

Of course, many people have contributed to my learning, but I can still say most of my experience and knowledge has come the hard way (and probably the best way), i.e. Learning/solving it on my own.

“Experience is the best Teacher.”

While I say this, I don’t at all mean to say that you won’t be benefited from learning or following documented theories about Software Testing. What I believe is, this all will surely help but nothing can beat understanding the concept at the core and facing the problems boldly.

I believe documented stuff won’t teach you real testing, though it can give you some direction and then you are on your own. At least in my case, there were problems which may be not documented to solve my exact problems or I couldn’t find them in time. My only choice was to understand the problem/situation at the core and react to it with the approach I found right.

Examples – How I approached in different situations

Let me explain this with the help of problems/situations I was up against and how I approached them.

#1) Business understanding is a notch higher over understanding testing

Well, you all know this. Testing isn’t just testing few validations and doing some verification.

As a tester, we are supposed to visualize every possible scenario, even the rarest of the rare scenario without fail. We are supposed to consider every possible test data which the actual user might be using.

For all this, we are supposed to understand the business to the fullest.

It won’t be wrong if I say we should understand the business and user base as much as or even more than a Business Analyst does.

I was facing similar odds.

I was supposed to understand complex business scenarios in the procurement domain, brainstorm the new requirements and weigh them from a user’s perspective. I was not only supposed to work out my cases but also contribute in the Requirement and Design phases of each iteration. Even here, no ready reference came to my rescue apart from my thinking and reasoning ability.

To understand the business better and design your scenarios/cases better, nothing works like pen and paper.

Also read => 5 Must Have Non-testing Tools for Testers to Make Life Easier

Before going to Requirement discussion meeting, I used to write down possible doubts/corrections/unclear points beforehand. I used to write down the scenarios I want to try or build test cases upon; sometimes, even drawing your scenarios works like a charm.

When you write/draw, it enters your mind with better clarity and then your mind works on this information and produces more scenarios and gives better clarity. This goes on till you get that feeling of DONE!!!

#2) Performing against the odds and in pressure

I was working on a product which was/is huge and complex enough to make a team of 30 engineers working continuously for three long years to get it to a sellable level.

For most of the initial phase, either I was up (solo) against a team of 15-20 developers ranging from the junior, mid-senior, and senior level or was accompanied by one or couple of other testers. They were all adding new features to product relentlessly, which required equal and parallel attention from the testing side.

Being part of requirement meetings, writing cases, executing them, exploratory rounds, maintaining servers, deployments, nothing was optional.

By then I wasn’t aware of any methodology, best practice, course or a book which can show me solutions to such problems. Even today I’m not sure if there is anything which can precisely help you fight the ground realities as you face them.

What I was rather doing is, aggressive and rapid rounds of exploratory testing (I wasn’t aware of the name by then) on each feature one-by-one and then repeat. This solution works purely on how fast you can shift your thoughts and frame situations/scenarios.

Of course, this demanded real fast and aggressive work but it worked for me.

What I mean by aggressive round is, you target one thing at a time (Say one element of a form at a time) and test it independently and in association with other linked elements/things.

Recommended read => How To Be A Productivity Junkie (Especially as a Tester)

E.g. How to test a Textbox.

What you can test here is:

1. Whether it accepts and stores data as is
2. Data type validation
3. Max length validation
4. Special character’s handling
5. XSS handling
6. Multilingual data handling
7. Handling of empty spaces/no data
8. Behavior of tab and enter keys
9. Error handling (cross-browser)
10. UI alignment (cross-browser)
11. Copy paste data/dragging links data to textbox
12. Most important – the behavior of this field w.r.t. other linked elements (any business expectation linked to this field like populating something in some other field based on the data in this field)

Does thinking about above testing give you confidence that nothing much can really go wrong with this field?

Well, targeting one thing at a time always worked for me and I used to get some work completion too.

#3) When you are up against the ‘unexpected’

Which book do you think will suddenly help you with ‘How to’ when you are supposed to do something you have never done before?

If we talk specifically then- None.

I remember the time when in the absence of our Product lead, I along with few other Junior and mid-senior members were supposed to deploy our application on Demo (was production to us then) instance for the first time. It was very critical for first ever Demo of our product.

Well, we did it, but with lots of Trial-and-Error. Reason being, none of us had expertise on Linux and shell scripting. I remember, there were concerns raised by our IT department (all in good faith) to my then Manager about me running wrong commands on Production servers. Maybe this was just a catalyst and shell scripting/Linux was my natural interest, but in a short while after that, I ended up taking responsibility of maintaining and upgrading five to six environments simultaneously.

Shell and Linux caught my interest so well, that soon I was the one who started conducting internal training sessions on it.

#4) When your performance is measured, your experience is not

Very early in my career, I was getting compared and measured against the very evolved and experienced testers around. I believe many of you must have experienced a similar situation and know what those extra expectations does to you.

The remedy here was to Push myself & Evolve.

The only way forward was to not think about how less experienced I am, not limiting myself by World’s standards of measuring how slow/fast I should grow/learn. Not limiting myself to World’s criteria of how soon one should start leading and the title one needs before doing it.

Well, around this point, I must say, irrespective of which field you belong to, I recommend you read Robin Sharma’s The Leader Who Had No Title. It will help you unleash what lies within you. It will tell you no one except yourself can hold you back.

If I have to bind my experience in few sentences, it goes like this:

“Your curiosity, attention to details, discipline, logical thinking, passion for work and ability to dissect things is all what matters to be a Destructive and Successful Tester. It worked for me and I strongly believe it will work for You. If you have these qualities, it has got to work for you.”

Well, reading this far if you are thinking that I am promoting basic human qualities over deeper theoretical knowledge, then that is not completely true. I believe to start with something and to taste success at it, it depends slightly more on your inbuilt qualities than on information you have learned. However, to go far in any field, you have to learn lessons, principles, and experiences.

In my case too, I had to learn the terminologies, concepts, theories to some extent as I reached further in my career. Reason being, as a tester you have to interact with several people who will talk in those terms and you got to understand it.

As a lead or a co-tester, you will have a new tester coming from some part of the world with his/her own knowledge of facts, definitions, and terminologies. Here too, you can’t stay passive towards these things; you got to have a prior knowledge about maximum possible things used/said out there.

Learning is inevitable.

I had to learn more about different types of testing, how to execute those and ways to explain it to people in my team at the right stage. I had to evaluate new ideas, tools and implement those. Learning new concepts and methodologies becomes equally important as you move up the ladder.

Read more => The A to Z Guide on Selecting the Best Automation

Conclusion

Though it is nearly impossible to write down every major and minute thing I have learned over years, this is my attempt to summarize it in a bulleted list.

• Testing is very tough to define. Someone can do superb testing and might not be able to define it in words. It is as you see it.
• Everyone can have their own definition of testing. Mine was simple- “You are given a thing – Find faults and make it better.”
• You don’t necessarily need big theories, complex matrices or ISTQB to be a destructive tester. You got to be curious, focused, and passionate, think logically and have dissect-ability. However, knowing extra doesn’t harm but not at the cost of losing the crux.
• The traditional approaches/concepts too have their own importance and I have equal respect towards them considering the fact there is a good part of the world where those are a just necessity. Testing alone can’t evolve; the surrounding also has to evolve for that.
• As a tester, it becomes equally important to learn new tools, techniques, and methodologies as you move ahead. Test planning, better approaches to perform different types of testing, Situational testing are a few to name.
• As testing is fluid, the definition of being a right fit also differs vastly from organization to organization. Being a destructive or excellent tester might just be good enough to get a pay cheque if you are lucky or it might demand extra knowledge of how testing works in traditional companies. Both are right at their own place. e.g. I hire people according to my definition of testing (which varies a bit as per candidate experience and profile of course).
• As there is a style of coding, driving, cooking; there is also a style of testing. You might not enjoy it unless you’re doing it your way. What I mean is Testing can have guidelines but it shouldn’t be hard bound by the micro-processes.
• The effective lead should make his team choose the work rather than assigning. He can occasionally alter it for the betterment of the Product.
• Try to train your people in their area of interest and along with where you want them to be trained. Align your team’s thoughts and efforts with end objective, which is ‘The Best Quality’.
• Don’t try to manage your people, lead them. Be friendly and approachable, it makes work a lot easier.
• Every member of your team should love the work they are doing, have an attachment to the product and are affectionate towards the people around. Then only the best of them will come out.
• The testing world has to evolve. Considerable part of World is moving to more practical approaches like Exploratory Testing, Context-driven testing (which many people do without knowing it is it) which even others should try and develop more techniques like the
• More Testing communities should be formed and like-minded people should get together on a larger scale quite There is so much to share, learn, adapt and innovate.

Hope my experience and findings helps you become a better tester or helps you in understanding testing better.

Further reading => From Beginner to Pro: A Complete Guide to Successful Journey of a Testing Professional

About the author: This article is written by STH team member Mahesh C. He is currently working as Senior Quality Assurance Manager having experience of leading testing front for multiple complex products and components.

Will love to hear back. Comment here or reach out to us. Thanks a lot for reading.