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

“You build a successful life…day by day…”

My journey into the realm of Software Testing kicked off rather abruptly.

I initially went through the primary interview stages assuming it was for a position in Development. To be completely candid, akin to many Computer Science graduates, I had some hesitations about delving into Testing.

Nevertheless, I eventually agreed to try it out, driven mostly by the conviction that my questioning mindset would be an asset in this field.

I wouldn’t have taken up the offer without asking this question – Is there a possibility of switching to Development if Testing does not pique my interest? :).

Believe me- After that, I didn’t for once think about leaving Testing.

During the technical round, I was not prepared for anything beyond the core idea of Software Testing. The thought that I was being evaluated logically rather than theoretically likely carried me through.

This constituted my initial lesson in Testing – I grasped how we (beginners) were assessed.

Even now, I adopt similar methods when hiring entry-level candidates for my team. I evaluate their logical reasoning, dedication and problem-solving techniques over anything else.

Suggested read => 4 Key Lessons I Took Away From My Journey as a QA Test Manager

I started with Zycus as a QA Trainee and within the first few days, was assigned to a product. This was one of the biggest projects (in concept at the time) and represented the company’s most ambitious endeavor. Once I had settled down in the first few weeks, there was no looking back.

We initially started as a two-person QA team and soon after a couple of months, I became the solo executor of all Testing initiatives. In a span of just 2 – 2.5 years, I had discovered almost 3000 faults spanning various categories such as Functional, Performance, Security, UI, Usability, Multilingual, Multi-Tenancy, among others.

For a significant period before the expansion of the Testing team, I was up against a robust Development team of 15-16 individuals. Despite an unfavorable Quality Control to Development ratio, even after the additions, I can confidently say that our journey was a success, given all we tested, produced, and managed.

A key highlight here is indeed – This feat was achieved with a practical understanding of Testing, not just theory.

I have been working in the Software Testing industry for close to six years now. It has been a remarkable journey filled with a variety of experiences and many valuable lessons.

Currently, I serve as a Senior QA Manager overseeing approximately 5-6 products and modules. However, what truly gives me a sense of accomplishment is leading a team of over 30 enthusiastic and satisfied Testers.

While there have been numerous individuals that contributed to my knowledge, I must admit that most of my learning and experience has stemmed from hands-on practice (and perhaps the best approach) i.e., independently learning and resolving problems.

“Experience is the finest teacher.”

While I emphasize this, it’s not at all suggestive that learning through documented theories about Software Testing has no value. My viewpoint is that these resources do aid in learning, however, nothing can outshine a firm grasp of the fundamental concept and the confidence to troubleshoot issues effectively.

I think documented material cannot impart you real testing skill, although it may provide some guidance, and thereafter, it’s indeed a lone battle. In my experience, problems arose for which no documented resolutions existed, or I simply could not find them in a timely manner. My only alternative was to comprehend the problem/situation thoroughly and address it using the strategy I deemed appropriate.

Examples – My approaches to various situations

Allow me to illustrate this with examples of issues/situations I encountered and how I navigated them.

#1) Understanding the business holds more importance than understanding testing

Surely, you’re already aware of this. Testing is about more than just validating certain parameters and performing some checks.

We, as testers, need to envisage all possible scenarios; including even the most unheard-of. We should take into account every conceivable set of data that the actual user could utilize.

For accomplishing all this, the importance of having a deep understanding of the business cannot be understated.

It wouldn’t be incorrect to claim that testers should understand business and user base as much as, if not more than, a Business Analyst.

I faced similar challenges.

I was tasked with understanding intricate business scenarios in the procurement domain, generating innovative requirements, and examining them from a user’s viewpoint. My role wasn’t limited to working on my test cases, but also contributing during the Requirement and Design stages of each cycle. In this event too, there were no readily available resources for my assistance, apart from my own critical thinking and reasoning abilities.

To enhance understanding of the business and design cases more effectively, there’s no better aid than the good old pen and paper.

Also check out => 5 Essential Non-testing Tools for Testers to Simplify their lives

Before attending a Requirements discussion meeting, I habitually noted down any doubts, adjustments, or ambiguous points in advance. I penned down scenarios I wished to test or base my test cases on; occasionally, sketching out scenarios was incredibly effective.

When you write or draw something, it is ingrained in your memory with greater clarity, and then your brain processes this data and generates new scenarios, granting you better understanding. This cycle continues until you reach that satisfactory feeling of completion!!!

#2) Performing under strain and against all odds

I was part of a product that, due to its sheer size and complexity, required a mounting effort from a 30-engineer team over the span of three grueling years to render it marketable.

For a majority of the initial phase, it was either me alone pitted against a team of 15-20 developers of varying degrees of experience, or I was accompanied by one or two other testers. There were consistent additions of new features to the product which necessitated equal and simultaneous attention from the testing aspect.

Being involved in requirement meetings, creating test cases, executing them, performing exploratory rounds, server management, deployments – none of this was optional.

Back then, I was not aware of any methodology, best practices, courses or books that could equip me with solutions to these issues. Even today, I am not certain if there is anything that can guide you accurately through the realities you stumble upon in real life.

What I was doing was executing extensive and swift rounds of exploratory testing (although I wasn’t familiar with the term then) on every single feature, one after another, while repeating the process. This approach depended on how quickly I could shift my thought process and formulate situations/scenarios.

Of course, the workload was heavy and time-consuming, but it produced results for me.

By intensive rounds, I refer to zeroing in on one thing at a time, for instance, one part of a form, and testing it in isolation as well as in conjunction with other related parts/entities.

Recommended reading => How To Be Extremely Efficient (Especially as a Tester)

To provide an example: The various ways to test a Textbox include:

Here are some possible tests one can perform:

1. Ensure it accepts and stores data correctly
2. Validate data types
3. Validate maximum length
4. Manage special characters
5. Deal with XSS
6. Handle multilingual data
7. Deal with empty spaces/no data
8. Monitor the functioning of tab and enter keys
9. Error management (cross-browser)
10. User Interface alignment (cross-browser)
11. Test copy-pasting data or dragging link data into the textbox
12. Most importantly – monitor this field’s response in relation to other linked elements (e.g., feeding data into another field based on the content in this field)

Does the contemplation of these tests give you the confidence that this field is thoroughly vetted?

To me, focusing on one element at a time always worked and helped me complete some tasks.

#3) Handling the ‘unforeseen’

Which manual, in your opinion, can instantaneously guide you on ‘how to’ when you come across something you’ve never encountered before?

If we narrow down the options, the answer is undoubtedly – None.

I recollect the instance when, in the absence of our Product lead, a few junior and mid-senior members, myself included, had to deploy our application on the Demo (considered the equivalent to production for us then) instance for the very first time. This was crucial for the maiden demonstration of our product.

Against all odds, we managed to do so, but not without a fair share of trial and error. The reason being, none of us were experts in Linux and shell scripting. I remember the concerns raised by our IT department (with good intentions, I might add) to my then Manager regarding me running incorrect commands on the production servers. Perhaps this served as a catalyst and my interest in shell scripting/Linux naturally developed. Shortly thereafter, I took on the responsibility of maintaining and upgrading five to six environments simultaneously.

My interest in Shell and Linux deepened to such an extent that I eventually started offering internal training sessions on these topics.

#4) Your experience is not assessed when your performance is

Early on in my career, I found myself being compared and evaluated against seasoned and skilled testers. I believe many of you would have encountered similar situations and understand how those heightened expectations can impact you.

The solution here was to challenge myself and evolve.

The only way forward was to overlook how inexperienced I was, not limit my learning pace based on global standards, and not restrict myself to the worldly norms of possessing a certain job title prior to assuming a leadership role.

At this juncture, I must take a moment to recommend Robin Sharma’s The Leader Who Had No Title to congregation of any hub. It will help you tap into your inner potential. It will reveal to you that the only person who can restrict you, is you.

Summing up my experience in a few lines:

“Your inquisitive nature, meticulous attention to detail, discipline, logical reasoning, enthusiasm for work, and problem-solving capabilities are the key ingredients to becoming a proficient and successful tester. It worked for me, and I am firm in my belief that it will work for you as well. If you possess these characteristics, you are destined for success.”

If you have come this far and if my words have given you the impression that I regard basic human qualities as superior to comprehensive theoretical knowledge, that is not entirely the case. I believe that to initiate something and attain success in it, your inherent abilities play a marginally larger role than the information you absorb. However, to excel in any domain, theoretical learning, adhering to principles, and gaining experience is crucial.

This also applied to my case as, I had to familiarize myself with the terminology, concepts, and theories to a certain degree as I advanced in my career. The reason being, as a tester, you have to interact with various individuals who converse in such terms, and you should be able to comprehend their language.

As a leader or team member, you will interact with new testers who hail from diverse backgrounds and carry in their own set of facts, definitions, and terminologies. Even in such cases, you cannot remain passive towards these things; you should already have knowledge of the maximum possible concepts and terms used in the industry.

Learning is never-ending.

I had to learn about different types of testing, how to conduct them and how to explain them to my team members at the right time. I had to assess new concepts, tools, and implement them. Adopting new theories and methodologies gains equal prominence as you ascend up the leadership ladder.

More to read => The Comprehensive Guide on Choosing the Perfect Automation

Final Thoughts

While it is nearly impossible to encapsulate all the major and minor lessons I have gleaned over the years, this is my attempt to summarize them in a list form.

• Testing is difficult to define. Someone can be an exceptional tester and still struggle to articulate it in words. It is as you perceive it.
• Everybody can have their own definition of testing. Mine was straightforward – “You are provided with an item– Identify flaws and enhance it.”
• You don’t necessarily need intricate theories, complex matrices or an ISTQB certification to be an efficient tester. You need to be questioning, attentive, passionate, logical, and have the ability to break things down into manageable components. However, additional knowledge doesn’t hurt, but not at the cost of missing the gist.
• Traditional methodologies/concepts also hold significance and I respect them greatly considering there are many regions across the globe where they are indispensable. Testing cannot evolve in isolation; the surrounding ecosystem must also evolve in tandem.
• As a tester, it holds equal importance to learn new tools, techniques, and methodologies as you progress in your career. Test planning, better approaches for different types of testing, and situational testing are examples of this.
• Being the right fit as a tester can differ significantly from organization to organization. Being an excellent and efficient tester might be enough to earn a salary if you are lucky, or it may necessitate additional understanding of how testing operates in conventional organizations. Both approaches are justifiable in their own rights. For instance, I recruit people as per my definition of testing (which can vary depending on the candidate’s experience and profile).
• Like coding, driving, or cooking, each having a unique style, testing too has its own style. You may not find it gratifying until you do it your way. By that, I mean, testing can have guidelines, but it mustn’t be rigidly confined by micro-processes.
• An efficient team leader should encourage their team to choose their work rather than assigning it. Occasionally, they may modify work assignments for the enhancement of the product.
• Endeavor to train team members in their areas of interest, in addition to areas where you want them to gain expertise. Align your team’s thoughts and efforts with the ultimate goal which is ‘Unmatched Quality’.
• Don’t try to manage your team members, but lead them. Be friendly and accessible – it simplifies tasks.
• Every team member should love their work, feel a sense of belonging to the product, and exhibit a caring attitude towards their colleagues. Only then can their best shine through.
• The testing world needs to progress. A significant segment of the world is moving towards practical approaches like Exploratory Testing and Context-driven testing (which many individuals already practice without being aware of it), and others should investigate and develop more techniques similar to these.
• More testing communities should be formed, and like-minded individuals should band together on a larger platform. There is so much to share, learn, adapt, and innovate.

I hope my personal experience and insights assist you in becoming a superior tester or enhance your understanding of testing.

More to read => From Novice to Professional: The Ultimate Guide to a Successful Career as a Testing Professional

About the author: This article was penned by Mahesh C., a team member at STH. Currently, he is employed as a Senior Quality Assurance Manager with extensive experience in leading testing initiatives for multiple complex products and components.

I am eager to hear your thoughts. Please leave a comment here or get in touch with us. Thank you for reading.