The Test Chat: The Tester Of The Year 2025 Recognition

 

To,

The Test Chat

I wish you a healthy and happy prosperous year 2025.  Let all your aspirations come true! 

I went into silence for a couple of hours on reading and knowing I have got this recognition and appreciation.  I did not know to respond.  I'm humbled and touched.  Respects!

Thanks for this recognition and appreciation.  It feels good!  This makes my 2026 start with a bliss.

I have to share this,

• I'm learning by listening and observing to everyone in The Test Chat community.
• This is helping me to be consistent in the efforts to improvise my practice each day.
• Hence, I owe this recognition and share with you all in The Test Chat community.
• I could share a bit because you all are sharing what you are having in full for us in the community.
• I owe a share to my seniors and peers whom I observe.

Such community recognition and appreciation come with added responsibilities and accountability.  Now, this has made to look upon myself much closely on how I conduct, communicate, unlearn, learn, practice and share with the communities and fellow testers.

I'm grateful for The Test Chat community.  Gratitude! 🙏

Thanks!
Ravisuriya

01st January 2026

The Test Chat's Tester Of The Year 2025

Recognition and Appreciation

My Experience With HOTS For Smart QA

In this year [2025] apart from attending the meetups, I joined two programs. One is HyBIST and the other is HOTS.  These two programs helped me to pause and rethink on certain topics, my practices and approaching. 

• HyBIST -- Hypothesis-Based Immersive Session Testing
• HOTS for Smart QA -- Higher Order Thinking Skills

In this blog post, I'm sharing my experience with HOTS.  

I start by expressing my gratitude to Thiruvengadam Ashok and Keshava Murthy.  The efforts and time these two are investing to consistently update and build the HOTS has to be recognized and appreciated.

I was part of HOTS 5.  It is the fifth edition of this program with 30 topics.  We had around 40 hours of discussions.  This edition had 18 sessions.

Pic: On the last day of HOTS 5 Cohort Session

HOTS, Engineering and Thinking

In my opinion, HOTS is not just confined to software test engineers though the program title is HOTS for Smart QA.

• It is to anyone in the discipline of Software Engineering.  
• A software test engineer will have an edge as one can find at least one more test engineer in HOTS.

HOTS is a program where one is put to varying thinking orders and dimensions from different perspectives. 

• The topics and discussion in HOTS starts from the why the need of a software to what it takes to consistently deliver value from deployed software.

In a way, it is a kind of rewriting one's own experience and lessons learned from others experience.  

• On rewriting it, how will one go ahead to engineer the solution in her or his work -- is a gist of HOTS outcome.  

When one gets this gist, one will realize, the software engineering is not just coupled to programming, testing, DevOps and business.  

• Instead, it is social engineering which involves the awareness and skills of different disciplines.  
• I learn, it takes years of practice to become aware of this.
• By being part of the HOTS discussion, it opens up one to this awareness in the early days of one's career.

Programming, testing, product engineering, orchestration and business's service delivery is not just technology and code.  It is a  social engineering which demands skills beyond programming and testing is echoed implicitly after each cohort sessions.  

Hosts and HOTS

Ashok and Keshav are giving their time for HOTS outside of their work-life and family life.

• It is not easy, to do this, as a routine for the scheduled program as HOTS.  
• These two cannot bunk a class in HOTS.  
• Hope you get the picture of how committed this program is!

The hosts are punctual to the classes.  

• Keshav shares the information and any updates on time in the messaging group, so that, the attendees are aware of the topics and can prepare for it.  
• Ashok ensures to remind the attendees about the upcoming class on the previous day of the class.  

Apart from this, these two take care of administrative tasks to run the classes smoothly.  

• I did not have any trouble or problem during the online classes and in accessing the resources of HOTS.

The hosts are available and will respond in the messaging group for the queries posted.  

• I have seen, the hosts picking up the questions which were posted in the messaging group and discussing it in the class.  
• The hosts do not ignore; they make sure we get the clarity and interpretations with perspectives on the questions.

I have seen the attendees gently not agreeing to certain perspective in the discussions.  

• And, the hosts welcome it and appreciate it.  
• I did not see anyone being judged or labeled in the HOTS.  
• All are treated and considered equal.  
• We are given the opportunities to share, and we are asked to pick the opportunity to share our thoughts.  
• So well and effectively the HOTS classes are moderated and regulated by the two hosts.

On top of this, the experiences of Ashok and Keshav in the industry, engineering, software testing and engineering, and life bring vivid richness to the HOTS.

My Hands-On Experience of HOTS

• I was not aware of the word 'cohort'.  I got to know it from the HOTS.
• Each session is a cohort; I have no second thought in it.
• The attendees in HOTS come from different
• Organizations, roles, backgrounds, understandings, practices, thought process, problem-solving approaches, perspectives, experiences and awareness.
• I prepared for each cohort sessions.
• I read, analyzed and interpreted the topics and its details.
• I made my points and noted the questions to share.
• This gave me a space to interpret each peers thoughts and their points.
• I had my take back from each peers irrespective of their experiences and roles.
• I had take backs from each sessions. 
• I don't remember a session where I sat idle.  
• I was engaged completely in each sessions.
• Each sessions have put me into reflection, retrospective, regression, relaxing, critical and lateral analysis modes.
• I did not bunk any cohort sessions.  I made sure, I attended each sessions.
• When I was late by 15 minutes to a couple of sessions, I made sure to know what was discussed.
• It is that fresh each sessions are and the perspectives from it!
• There is no right or wrong in any thing shared -- this was told by hosts to all of us.
• It is how we are placed in the context makes it close or not close to what looks the solution or acceptable reasoning.
• We peers correlated and connected the different perspectives and learned from it.
• The disagreeing to anyone's thought happens professionally and it will be acknowledged.
• I observed, the disagreeing or agreeing was to the thought and not to a person. This is important to notice here!
• Each attendees welcomed the perspectives and awareness of other peers in the cohort.
• When I worked on the nudges and reflection questions,
• It helped me to recall my works.
• That way, it helped me to eliminate what I had to and start with a different mindset for today's needs.
• I could go deep into each of these exercises and think critically, or, figure out what I can do differently to solve the same problem.
• I also made use of HOTS 5 to exercise and improvise my communication skills.
• It helped me a lot here!
• These below fundamental skills of all disciplines were exercised in each sessions.
• Questioning, Interpreting, Hypothesis, Reasoning, Logical Analysis, Pattern Recognition, Communication and Presentation.
• Every area of Software Engineering was touched and discussed.
• For example, 
• How critical is the time analysis and drawing the analogy of Big O notations in software engineering.
• There is no randomness thought it has the word Random
• There is a definite defined and accepted boundaries in the said random.
• An example of Random Forest algorithm and how it works.
• And more such topics
• The hosts did not rush to complete the topics of the week.
• Instead, the hosts ensured, there was a value oriented discussion on each topic.
• At times, the cohort discussed just one topic for 2 hours.
• It was not an easy emotion for me on the last day of HOTS 5.
• I miss the Tuesday discussions which started sharp at 8:30 PM IST.
• My key take back from the HOTS 5 are,
• The perspectives each peer shared in how they attempted to understand the problem before solving it.
• The representation of tests in the layers to ease the communication.

I thank with gratitude to Ashok, Keshav and all other peers of HOTS 5.  Your time, presence and interpretation has helped me a lot!  I'm building upon it.

References:

1. https://smartqa.community/
2. https://smartqa.community/hots/
3. https://www.linkedin.com/in/ashokstag
4. https://linkedin.com/in/keshava-murthy-k-n-a623034

STeP-IN Summit 2025 and My Experience

 

I start this blog post by expressing my gratitude.  My gratitude to STeP-IN and Vinay Baid.  I attended STeP-IN's 22nd International Conference on Software Testing, on 19th September 2025. 

This blog post is about my experience with STeP-IN Summit 2025.

I'm not paid or asked to write this.  I'm writing to document my experience and observations with STeP-IN Summit 2025.

The Conferences and Me

STeP-IN Summit 2008 is my first testing conference.

Since then, I'm seeing how the conferences around Software Testing & Engineering is shaping and continuing.  Together with the conferences and STeP-IN Summit, I'm shaping and continuing to grow.

For me, the conference[s] look as a timeline and the tree.

• It reflects the past, present and talks about tomorrow.
• In that, STeP-IN Summit shows the landscape of thoughts and drifts around the software testing practice for the last two decades.

I see the series of changes, transformations and trajectories in Software Testing as an industry.  I see the changes in conferences as well.

One of the conferences which is consistently attempting to capture it and get its gist to the test engineers is STeP-IN Summit.  Further, it emphasis on the practice of software testing.

Conference and Take Back

What do you take back from the conference?

Whatever you took back is what you tried to see.

If you want to experience and know the conference and your craft, you should walk in between the attendees in the conference, listen to them, and talk to them.

• You will know what's happening -- inside and outside.
• Inside and outside of what is said in the conference.
• Inside and outside of the one who is attending the conference.
• Inside and outside of you!

If you go to conference and meetup just to listen to the speakers and panel, may be you will not know about your craft, industry and what's happening.  

It is the attendees who carry the torch light. Talk to them.  Know what they are doing, why and how.  Network!

The speakers, panel, vendors booth and sponsors they attempt to show the drift, by calling it theme sometimes.  Is the drift being spoken is the actual drift? This is, uncertain.  Talk to the attendees.

To see the drift with current state, you need to find the torch light.

Find your torch light in your upcoming conferences and meetups.  Catch the drift and surf the waves.

I and STeP-IN Summit 2025

I thank the organizers and Vinay Baid for inviting me to STeP-IN Summit 2025.

This was my in-person software testing conference after 6 years.

I started at 6:30 AM to conference.

• I reached on time and collected my tag.
• The conference's reception was well organized.
• I moved to the conference hall; I see, it is full. I stood at the back.
• The conference's lamp lightened up and got a kick start!

I met my seniors in the conference.  They spotted me and gave a few minutes of their time to me.  I'm happy and grateful.  I see, people value for what you are and what you share.

I listened to talks and panel discussion.

Also, I was moving in between the people outside the hall and in the hall.

• I introduced myself and conversed on multiple subjects.
• I went to each booths outside the hall and learned what they are offering.
• I looked for TestAutothon participants and conversed about the problem statements, and how did they approach their solution to it.

Talks and Distance

After the conference, I took BMTC bus [Bengaluru city's public transport] back to home. It is a long way to home.  These talks replayed in my mind as I traveled the distance to home.

1.  Rahul Verma's Man, Machine & Mischief: How I Co-Wrote a Testing Satire with GenAI

• I see, this talk is a journey shared.

• The journey which shares about self, writing, learning, perspectives, technology, GenAI, co-authoring, book, raising the bar each time, not giving up, design, book publishing, emotions, and testing.  There should be more to it; I could see these.
• What I recalled from this talk is,
• His journey of writing book - The Last Book On Testing.
• How he used the GenAI, while learning how to use it better each time.
• Challenging the ChatGPT models and its responses.
• Not just functional. Beyond functional responses.
• Taking the help of ChatGPT models to co-author.
• Testing the responses and fine tuning the prompts by expressing the personalities.
• Not just the persona; it is personalities.
• He engineered the prompts.
• How he identified the gaps in this tech and learning how to use the GenAI.
• This talk helped me to learn the hindsight behind the book "The Last Book On Testing"
• Per my understanding, Rahul has tested and testing the idea of GenAI.
• In this practice, he has experimented with ChatGPT models to understand the internals and externals of GenAI ecosystem.
• He experimented using ChatGPT models to co-author his book
• Wow!

Meeting Rahul in-person after years is happiness!

Though, I did not converse about testing, automation, engineering, and GenAI, I spoke to him.

I'm happy and surprised to reflect that we both can talk non-tech and non-testing.  But, we understand and know testing is elemental and has its presence in each systems not just the software systems.

2.  Raveendra Chakrakodi's Staying Ahead of GenAI Humanoids

You do not forget some people to whom you listened and spoke in conferences and meetups.  JP is one such person to me.  Now, Raveendra is another such person.

• I will remember this talk of Raveendra Chakrakodi for years.
• It was a 15 minutes talk which reached almost everyone I hope.
• It requires courage to do such talks and share with the audience.
• The audience could connect and feel the connection to this talk.
• He said, he manifested to do this talk day before the conference.
• And it happened!
• The another talk that I remember for years is from Jayapradeep Jiothis [JP].
• This is also a talk in a STeP-IN Summit 2019.
• The audience got up from chair and gave their claps to JP's.
• I will remember this talk of JP for all time.
• These two talks are not completely tech.
• But, these talks are around the life of the people in the software engineering.
• I recalled,
• Jayapradeep's talk as I traveled back to home.
• And, I conversed with the thoughts shared by Raveendra.

3.  Rajarajeswari Rangasamy's Autonomous Testing: The Next Frontier in Quality Engineering

• What struck to me and probably to all others is her body language and voice modeling, when she started.
• I recalled,
• Her body language, short punches, eye contact, and stage presence
• And, Wagile :)
• Waterfall + Agile

When I come across her upcoming talks, I will listen to it.

4.  Ramit Manohar Kaul's Metaphors and Audience Engineering

Ramit co-hosted the summit.  

He conversed with audience.  I have hosted the conferences and meetups.  So I say confidently, he conversed with audience.  He made it look so easy while it is not.

I want to call his hosting as -- Audience Engineering and not Audience Engaging.  As a host, he just did not converse; he shared insights.  This cannot be experienced in all conferences and meetups.

He gave the metaphors to the audience.

• The metaphors of daily life to relate with the tech stacks around the Transformers and GenAI ecosystems. 
• This was a bang, to me!
• I could easily recall and connect to these metaphors and visualize the ecosystem of Transformers and GenAI.
• I wish he gives a talk with the metaphors and it gets recorded, and will be on social media.  I have requested him for this. :)

He engineered the attention of the audience with his wits, humor, messages and insights.  I admire this personality of Ramit too.

I recalled those metaphors and our conversations.

I met Ramit after years.

• I see, we both see the journeys, time and transformation, and embraced each other.
• I feel good!

Conversation with Shrinivas Kulkarni

I met Shrini, my senior.  I got to know there is something called blog by reading his blog in 2007.

I could ask what all I had in my mind at that point in time.

• He shared and explained his perspectives and thoughts on career, roles, industry, layoffs, job, and life.
• I'm happy that I could talk about this with him.

I recalled the insights he shared and the examples he gave, especially the one of manager mindset and individual contributor or engineer mindset.  This example helped me to simply my thoughts around the job roles.

Found The Preface For Book - The Last Book On Testing

When Rahul announced he is authoring a book, I saw the book title having the word "testing".  I pinged him saying, I will be happy to review his book and it is a privilege and honor for me to do so.

Later, reading the teaser he posted for the book, I realized, I could not have reviewed it.  Today, I'm not equipped and skilled to do so.

When he published the book, I read the sample on Amazon Kindle.  I said to myself -- I'm not yet ready to read this book!  

But, how and when to be ready?  I had no answer nor clue to it.  Hence, I did not buy one.  I did not want to buy the book and keep it untouched.

The talk of Rahul in STeP-IN Summit 2025 helped me to see the book.  If I had not listened to this talk of him, I would have said myself -- I'm not yet ready to read this book!

Each book has a preface.  I see, this talk of him is an excellent preface to the book.

• An excellent preface to tell about,
• The book -- The Last Book On Testing,
• GenAI, ChatGPT models,
• Conversation with models, and
• Rahul Verma's experiment in book writing using ChatGPT models and the experiences.

I understand, if one do not listen to this talk, one might not get the author's intent and its pitch voice.  

Is that fair?

• When co-authoring a book together with an assistance of a software technology, it is necessity.
• Why?
• That's how you will see the inner side of the author and what did he do with the technology.  How? Why?

And, for someone who is peeling the layers of GenAI and Transformers in her or his practice,

• The narration of this book will be intriguing.
• Because, it is the reviewed and fine tuned versions of dialogues,
• Between, 
• The probing engineered prompts of the author, and, 
• The responses [to the prompts] from the Transformers and its attention.

I could see the dots now.  I saw, maybe a 1% of what Rahul saw and he is seeing.  

This is enough for me to find other dots and connect for reading the book.  Now, I have the context to read the satire -- The Last Book On Testing.  I'm ready!

I moved to the counter and bought one with a discount.  I wanted to pay for the book, buy, and read it.  That is one of the ways I can show my respect to the book's author.

But, Rahul had said, he will give me one copy of his book.  His humbleness!  Thanks, Rahul. :)

I collected it from him and he signed it for me.  Here, you see it.

Picture: The book that I got from Rahul Verma. :)

This, the one I bought, I got it signed it as well.  I will be gifting to a test engineer who deserves it.  I am yet to find one, now. 

Picture: The book that I bought and got it signed to gift.

In short, this talk of Rahul Verma is an excellent preface to the book and for his experiences of co-authoring together with GenAI technology.  

I wish, this talk's video recording will be published on the social media.

When I get the essence of the book and can consume its perspectives, I will share my experience as a blog post.

Ah! I forgot to say this.  As I listened to Rahul's talk, I got an idea on how to see this book, read this book, and reflect.  I shared the same with him.  And, he did say one of the reader and reviewer did that.

To summarize,

• Thanks STeP-IN and Vinay Baid.
• Gratitude!
• Thanks Rahul, Ramit, Shrini, Vipul
• Thanks to my seniors who gave me their few minutes and a pat.
• Thanks to attendees who gave me their time as I moved between them and conversed.
• Thanks Raveendra Chakrakodi for standing up and speaking your soul.
• I will be travelling distance with the dots I have collected [and collecting] in STeP-IN Summit 2025.
• I got a much needed preface to read the book -- The Last Book On Testing
• One request that I have for STeP-IN is to publish the videos of talks.
• This is a long standing request. :)

In Memory of Sridhar Venkannachar -- My Engineering Manager

In this post, I want to tell you about Sridhar Venkannachar.  When I started my career, he was my Engineering Manager.

Today, we see more Engineering Manager roles on the floor.  But then in the 2000s, it was the role one got on delivering the staff and principal architect roles.

I see, the managers and lead engineers do not get appreciated by their teams and business units in open and public.  Or, it is not a everyday experience is what I learn.  To all this, Sridhar is an exception.  

It has been 19 years to this date, since I knew him.  I have never heard anyone speaking something lousy or not the good about him.

He passed away on 09th June 2025 around 10 PM IST.  He was driving back from an engagement ceremony along with his wife.  He experienced the sudden chest pain and tried to stop the car by slowing it down.  He could not stop; but, he slowed down by hitting it to the median (divider) in the road, so that, others on the road do not get hurt.  No one is injured on the road and neither his wife.  The passers on the road tried to help and revive him, but, by then he had collapsed to a massive heart attack.  Last month he had his complete health check and the reports said all good.  He had no blood pressure, diabetes and any other medical conditions.  This massive heart attack came all of sudden to him.  

What Makes Him Distinct and "Our Engineering Manager"?

1. He has the smile no matter what the situation is on the floor.
2. He is healthy, fit, and agile with a dynamic personality.
3. His calmness irrespective of the problems being solved.
4. He makes sure his team and people do not go through needless stress and anxiety.
5. He embraces uncertainty and he is beside the team and people in getting the certainty of the context.
6. He solves the problems and helped to solve the problems.
7. He asked the status as, "Did you get a chance to have a look at it?"
8. He asked, "How can I help you?"
9. He never stepped up saying I will solve and do everything.
• Instead, he gave the engineers an opportunity to pick new challenges and responsibilities.
• He mentored them to deliver the solutions to the challenges.
10. He came to my cabin, and asked, "Do you have any questions? Let me know! I'm waiting for them.".
11. He is a people manager.
• People approached him though he was a technical and engineering person.
12. I knocked his door whenever I had a technical doubts and questions in the tech stack and projects.
13. He said, "I'm waiting for what you will be reporting. Take your time.  I'm curious to know what you bring now!"
14. He consistently strengthened the engineering practice and culture on the floor.
15. He listened and gave importance to the discussions, unit testing, testing and opinions of the programmers and testers.
16. When I ran automation overnight in the lab, he came to lab and sat beside me to know how the automation run is able to identifying the performance glitches.
• He wanted to know and paired along with me to investigate and debug the Out Of Memory incidents and growing heaps.
17.  I never felt he is superior. 
• Instead, I felt, I can always go to him or he will come to me when he see, I need him.  The same was the experience to any others and for the seniors in the org.
18. His people skills and tech skills are of high standards that has set me an example and one of the benchmarks.
19. He invited the testing team for the project, tech and release discussions and he expected that we were part of it.  He looked in deep attention and keen for our inputs and thoughts.
20. I never knew about Agile in 2008.  It was the starting days of Agile Methodologies and practice.
1. He use to talk, read, explore and implemented its practice.  I asked him, what it is.  He explained it in gist.
21. I felt, the team can play and have fun with laughter and smile.
• He did that and said the team to have fun and be cheerful.
• He made sure, he said what is expected and how we have to work along to deliver it.
22. I did not see a day where he was shouting or yelling or blaming.
• Instead, he listened, spoke with calmness and smile, and helped the engineers to solve the problem.
• He never showed unhealthy emotions, expressions and language despite being in that role.
23. Till a few months back, he gave a call and asked,
• How will you test and automate by giving an alternate example of a problem?
• How you test architect to solve this problem?
• How will you test this engineering work with these tech stacks?
• How will you go layers down into these hardware, OS, network and what will you learn to test here?
24. While he himself being an amazing software engineer and skilled architect, he asked and listened to a Test Engineer.  He made notes of the discussion.
25. He remained as a student till this day.
    

I can keep listing about him.  It does not end!  But, I pause here, for now.

Those discussions about CORBA and Messaging, and, the hardware interfaces keeps buzzing in my ear to this day.

He came to my cabin and looked at the poster "Testing Garage" below my name.  And, he further looked into my planners and read them.  He always said, I read your debugging and bug reports.  He never missed to respond for the overnight automation run reports, where I marked, the vitalities showing variations.  Such encouragement and support from him made me to practice software testing with enthusiasm. 

He never spoke ill or low about the Testing or Testers or any others.  As a result, my starting days of testing got its nourishment and support I needed to build the skills.

His legacy will live on!  

I heard the same today from the entire Datacard Software India people, irrespective of their roles.  Today, none of us work in the same org, yet, everyone shared about their relationship with him and how beautiful it is!  Note that, all spoke more about the beautiful relationship.

We both worked on the memory, heap size and objects for months.  Today, I write a "in the memory ..." blog post for him.

I wish, we all find and work at least with one such manager in our career span.  He or she will let us know and learn how to treat one with dignity, respects and values for first along with professionalism.

Today, I was able to glimpse him for one last time.  I thank the universe for this.

Dear Sir,

You will be in my memories and work.  

I know how heavy it is to your family, when we can see it, in us.

Your footmarks will be there for all time in my testing, engineering deliveries and professionalism.  A few live on no matter how long or short their time is.

 

Miss you! Gratitude and Respects!  

Inspiration and the Mentor Who Guided Me -- Part 3

 

Here is the first blog post of this series where I share how I started my Software Testing career.  I continue with the next question in this blog post.   The second question from Trending in Testing is -- "Who is your inspiration or mentor to guide you towards your journey?".

To start, I will thank my fellow testers and programmers with whom I worked and working today.  They influence my practice to get better each time.  I continue to learn from them.

People and Networking

I had just stepped into the second year of my Software Testing career.  One evening, I went to the desk of my friend and colleague Kantharaja MP.  He was reading the blog Thinking Tester by Shrinivas Kulkarni.  I got curious and asked what it is.  I did not know what the blog is then.  He explained to me what the blog is.  I got to know Shrinivas Kulkarni, James Bach, Pradeep Soundararajan, Ashok T, Rahul Verma, and Michael Bolton from the blog of Shrini.

Further, I got to know Vipul Kocher, Rahul Mirakur, Meeta Prakash, Ben Simo, Scott Barber, Gerald Marvin Weinberg, Martin Fowler, and Dr. Cem Kaner.  I connected with these practitioners and started to observe their practice.  Thanks, Kantharaja MP.

As I continued, I met Ajay Balamurugadas, Santhosh Tuppad, Parimala Hariprasad, and more friends who joined this network.

I'm continuing to connect with practitioners every day.  I interact, I observe.  I'm learning from each person with whom I interact.  I'm learning by observing the work of practitioners with whom I do not interact in person.

Mentor and Mentoring

I see, we must set out to find the mentor in our journey!  Find your mentors.  Yes, I said mentors and not a mentor.

My Mentor

I did not have a mentor.

I wish, I had a mentor who could connect, understand and help me to be competent, and know the craft, industry, and skills.  I continued to practice and learn from my mistakes, and by observing other practitioners.

I was seen as fun and the topic of fun for my attire, how I spoke and I write the English.  This made me distant from people whom I approached seeking help.  Today, I understand, could be this is the help I was offered for being better and I feel good about it.  I continue to respect them.  These people have inspired me to practice better.  I silently observed how they practiced and I experimented to develop my ways to practice.

I seek and step up to learn from all people when I see that, I can learn from a person or they can help me to learn.  This is doing good for me!

Today, I seek the help of people in the community by approaching them for their suggestions and guidance.  I give the credits and say their name in public and this is important.  I apply the suggestion, guidance, and what I learn from this appropriately based on the need and demand of context.

Ravisuriya as a Mentor

Today, 

• I want to be a mentor who understands the mentee and assists in the practice
• I want to connect with a mentee and listen

I understand,

• Each person is unique and comes with different
• emotions
• mindset
• attitude
• family situations
• personal life situations
• physical health conditions
• mental health conditions
• aspirations
• problems witnessed, and 
• connecting frequency levels
• and, it varies every day with a person

I try to connect, listen, learn, and assist where I can.  I'm a jovial person but at the same time, I'm committed and disciplined when it comes to practice and working.  I see the fun where we all enjoy and get involved in the learning, practice, and work.

Working with a Mentee

I do not associate and work with a mentee by seeing:

• her or his social identity
• how his or her English is
• how she or he appears in dressing
• how she or he socializes and opens up to conversing  

All these are needed in the professional life of a Software Engineer.  I do not deny it.  These have to be groomed every day.  Today, I want to and will dress better than I did in the early 2000s.  I speak!  I express what I have, feel and think, and communicate.

But, it is not a mandate to me for listening to a person (mentee) and get started unless I can't make enough time to assist.  These all will change gradually when one sees self and puts in efforts to get better.  And, a mentor has a role to play here as well.

If mocked for this, probably the mentee or whoever wants to be a mentee will build the distance and more barriers.  This will disturb the communication and relationship between the mentor and the mentee.  All have different conditions and environments in which we grew up and it has an influence on a person (mentee and mentor).

I look for how serious, disciplined, and committed is the mentee in progressing where she or he wants to aspire.  I see the communication is consistent in whatever form between the mentee and mentor.  By the way, communication is not English; the spoken language is one of the mediums through which we communicate.  And, English is one medium to communicate in the communication.

I try to see how can I assist and to what extent.  If I can, I will assist; if I do not have the skills to assist, I will try to connect them with other practitioners who can help better than me.  I talk and make sure we smile together in discussions.

I do not make fun of a person who asked for help and assistance.  I wish no others undergo what I went through.

Find your Mentors

Having a mentor helps very much! 

Find your mentors. Have more than one mentors who have

• the different thought processes,
• ideologies,
• thinking style and pattern,
• different experiences in the area of your practice,
• contrasting questions and approaching ways to learn and solve a problem,
• practitioners of different roles in your field of practice and work,
• practitioners who are not from your field of practice and work,
• and, now you continue to add more to this list ...

Most of the time one will fall into the trap of having a mentor who has got similar thought process and ideology.  This is good.  But, it is never enough to see the perceptions of your subject, work, and practice.

Connect to people of different ages and more importantly who have gone through what you are going through and also who have not gone through it.  

You and your mentor should be able to connect and offer what you both can exchange in return.  Mentorship is a relationship and a partnership where you share and receive.

I try to learn consistently that, the mentor does not have to be older in age and industry experience than I have.  A mentor is one who is able to give and share what I'm looking for in the journey and thereby helps to grow and transform me into a better version each time.

Find your mentors!  Connect to them.

How I Paved my Path into Software Testing! -- Part 2

 

I did not want to cut short sharing my experience for the below question.  I want to write what I want, to share about my journey to my first Software Testing job.  The question from Trending in Testing: -- "Could you please share your story about how you paved your path into Software Testing?"

College and Job Hunt

In 4^th semester, I decided to take Software Testing as my job.  I practiced Java 2 then, and using Core Java is one of my skills.  But, in college, we were said not to pick Software Testing as a career and job but instead to pick programming as a job.  The way I debugged my own code, it showed me that I’m doing better in testing each time.

On graduating B.E. in the year 2005, I walked to the public library to read the Times Ascent every Wednesday. I made a paper booklet that fitted my pocket and I wrote the email-id of companies who published (advertised) the openings and hiring for Software Engineers. All the openings advertised were for experienced software engineers.  I made note of all these email-id published in the Times of India's, Times Ascent. I hardly remember any call for freshers then on Times Ascent.  I did write a cold email to every advertisement for a Software Engineer job published in Times Ascent.

I walked to Software Companies in Bengaluru, asking for the email-id of the HR or email-id to share my fresher resume. I noted them in the booklet I had in my pocket. I gave the hard copy of my resume to the front office staff and asked them to share it with HR. Also, I mailed my resume later and asked for an interview opportunity saying how I will add value though I'm a fresher. I did not hear back!

Then, browsing at the internet centre was on the 52 KBPS modern telephone line and priced at 40 to 45 INR per hour. I had to mail around 30 to 45 individual emails in an hour with that choking internet. I had a credit account in the internet center as I extended 15 to 20 minutes each time, and it cost me 25 INR more. Today, do we have internet centers today in cities?  We do it all on a smartphone now most time.

Interview and My First Job

Those were the days that saw 6000+ freshers in a walk-in drive.  On one Wednesday, I saw an advertisement in Times Ascent from Datacard Software India Pvt. Ltd., looking for senior and lead engineers in Java. I wrote an email and shared my resume saying I'm a fresher and can use Java to program. I did not hear back from Datacard. 

After two months, I got a call from Radhika Muralidharan, the HR head of Datacard, India, asking if I was available for giving the interview. I said, YES!  

The first round was Java programming, and it had ten programs. I wrote the programs, all ten programs; I could see the confidence in me. I got a call after a week for the second round.  

In the second round, the interview panel had Srinivasan Rao the MD of Datacard Software India, and Vasu, the engineering manager. The questions were on Linked List and Double Linked List. I had the idea for these Data Structures; I wrote the programs for traversing the list and nodes.  But, I was not pleased with the logic, and I took 30+ minutes for two questions. The questions were about my logic, and I said, "it does not look good to me". 

This is the feedback I received in this round -- "You are good in Core Java; now you will have to work on Data Structures and optimize the same".   I acknowledged and accepted it.   But, I was confident in the way how I tested the logic I wrote for Linked List and Double Linked List and how I reasoned my logic is not a good one and why so.  I was said to leave as I did not meet the expectation.  I was not happy!  I practiced the data structures better.  I did not even know that data structures are a need and it is most expected in the interviews, then.

I continued my job hunt in walk-ins that saw 6000+ freshers. Three weeks later, I got a call from Radhika Muralidharan. She asked if I'm still looking out for a job, and if yes can I collect the offer letter at 4:30 PM. I said YES!

I was 30 minutes early for my interviews and on the day to collect the offer letter. Radhika spoke to me and asked to be seated in the meeting room. After 10 minutes, Srinivasan Rao came to the meeting room with an offer letter. He said, "What if I offer you the role of Testing?"

Ah! I needed a job. I wanted to be in Software Testing. I was offered a job in Software Testing. I said, "Sir, I will be happy, and I will do my best."  

He said, "Your skills are unique; you and we can benefit from your testing. Can you join on 6th July?".   I said, "I will start tomorrow." I still remember how Radhika and Srinivasan smiled at me when I said that.

I'm happy Software Testing choose me.  I'm happy that I got a job, and I got what I wanted as my job! I'm a Software Test Engineer by choice.  I'm glad, Software Testing is still holding me and uplifting me each day.  I'm a student of Software Testing & Engineering.

I Convey My Thanks and Gratitude

I thank Radhika for looking at my email and for the opportunity she gave me to give my interview. If she had not marked my email to call me for an interview, I don't know!  I thank Srinivasan Rao for the opportunity he gave me. I remember these two people, and they are in my thoughts. I'm grateful for the confidence they had in hiring me. Thank you, Radhika and Srini.  This job helped me to help my family.  I asked my mother to stop making agarbatti's and relax; she was doing it to support the family.  My first salary was 13000 INR.

I had four rupees in my pocket that evening. I looked for a coin telephone box on MG Road. I called my mother to tell her I got a job. up  I called my childhood friend Kantharaju to say I got a job; he picked me that day back home.  

I was on a project the next day with requirements, test cases, and design documents. The tasks were defined with timelines to deliver. Kalyan Kumar, the project manager gave me the book "Effective Methods for Software Testing" by William E Perry. He marked the chapters to complete reading in a week. That is the first book that I read to know and understand the approach and process in software testing.

I started my Software Testing career happily.  I m a Software Tester Engineer by choice.  I believe, Software Testing chose me and I'm grateful for it.  I'm a student of Software Testing and continuing my practice confidently amidst all the chaos that is surrounding Software Testing as a practice and career, today.  

And, this is how I started my Software Testing career.

Questions from Trending in Testing -- Part 1

 

This series of blog posts was supposed to be an article for a testing community.  I'm sharing it here on my blog as I could not finish it on time and respond to the moderator of the community.

On reading these questions, I wrote a draft for it.  I saw what I wrote could not fit into one post.  I tried to make it into one post.  But, doing so, I felt, I'm not doing justice to myself, to Treding in Testing for asking me to write, and to the reader who will be reading it.

As a writer or author of an article or blog, for first I have to enjoy my writing and its content, right?  I have to feel it.  Only then, the readers might feel what I write.  I did not get this feeling when I tried to fit it into one post.  Because, the questions were so contentful in itself. How to bring the value for those good questions?

I decided, I should be giving the credits to Trending in Testing and to make these each questions into a blog post, so that I do justice for the questions, to Trending in Testing, and to myself.

Search for Trending in Testing and read the interview of other practicing Software Test Engineers. Thank you, Trending in Testing for asking me these questions and any credits for this will be to you.

I was asked the below questions and I'm making each question as one blog post.

1. Could you please share your story about how you paved your path into Software Testing?
• Blog: How I Paved my Path into Software Testing! -- Part 2
2. Who is your inspiration or mentor to guide you towards your journey?
• Blog: Inspiration and the Mentor Who Guided Me -- Part 3
3. What are the common challenges that you face as a Software Tester? How do you overcome them?
• Blog: Common Challenges as a Software Tester; How I Overcome it -- Part 4
• Blog: Practice: The Top 5 Challenges I See For Today -- Part 4A
• Blog: Business: The Top 5 Challenges I See For Tdoay -- Part 4B
• Blog: Project: The Top 5 Challenges I See For Today -- Part 4C
4. What can people in the same role do to upskill themselves so that they can keep pace with the changing trends?
• Blog: To Be Contemporary in Software Testing & Engineering -- Part 5
5. According to you, what are the important factors to consider for becoming successful in Software Testing?
• Blog: What is Success to me in Software Testing? -- Part 6
6. What are the upcoming trends in Software Testing that our audience should know about?
• Blog: Difference between Software Testing and Upcoming Trends in Software Test Engineering -- Part 7
7. What advice would you like to give to aspiring testing enthusiasts regarding how they can pave their way in the industry and be successful?
• Blog: The Advice to Test Engineer in Me -- Part 8

When not to test? When is the no need of testing?

I saw a tweet interacting with me and it was from my colleague Pradeep Lingan (PL). He had shared a question -- When to start test once the build arrives?

When to start test once the build arrives? @testingGarage @moolyatesting

— Pradeep Lingan (@Pradeeplingan1) March 15, 2017

I was in silence for few second on reading this question. In silence, I asked myself, "Why should I test? Why at all I should start testing in whatever timeline of product development?" Now, I have two questions, the one from PL and the other which I ask for that question.

The question asked by PL is not always easy to answer. But it is a very logical and technical question which should be answered. If not answered, stakeholders involved and those who are expecting 'valuable' (if expecting valuable) from testing will happen to ignore testing.

I wanted to ask PL what is the context in which he is asking this question. You see, it is not a simple question. It can be better understood when known the context which raised that question.

As a practicing tester, I understand, when there is contextual question, it is also possible to derive questions which is context free. When I say context free questions, it is the question which is generic and can be used along with contextual questions.  Is context free is also a context? I will leave this to you for brainstorming.

I will not ask PL for context here. I will answer my thoughts using context free learning approach here. From there, I will let PL to brainstorm with context for the question he asked.


Why we test? When is "the need" for testing?

I learn, I test and purpose of the Software Testing is,

• To provide information on product, so authorized stakeholder make sound informed decision on product's development, scope of development, pause, abort and release
• Information on testing the product can be -- about it's quality criteria and risks around it; and about the risk of carrying out and not carrying out the testing in context
• Information obtained from testing can be used for -- to make decision about the product; about the decision which stakeholders going to make and risks out of it; if it is worth to pay for tester, testing team and seek the information which is being received; are we investing too much for information that's not worth; prioritization; should we carry out much more testing and better testing?  etc.

Software Testing is not about fixing. Software Testing is to assist the fixing in better, rational and empirical way. The information obtained out of testing to be used for bettering the product. That means if carried out testing, it does not mean, it improves product. When information out of testing is used to better the product by fixing, it helps the product to improve.

The above points should have helped now to start understanding the Software Testing and its service to development of product and stakeholders. If I and you mutually agreed for above points, then you are looking for information which can ruin the existence of product or purpose of building the product or something that will incur loss to everyone in the business.

When not to test? When is "the no need" for testing?

On reading why we test and when testing is needed, it is quite straight simple to know when not to test and when is there no need for testing.  This can be used as a start point to decide whether to start testing or stop testing.

In below cases, it is useful not to test

• When a tester and testing team has no clarity in knowing -- what is useful testing and not useful testing for stakeholder
• When we don't know about risk(s) on which the testing has to focus in product and provide information
• When we have no clarity on what is expected out of testing
• When a tester or stakeholder feel the outcome of testing being carried out is not going to help in making the decision
• There is no area or a question in the product for which testing help to see an answer
• When no one is interested and curious in outcome of the testing

In below cases, there is no need for testing

• When the stakeholder learns or believe and say there is no risk in product, and say to stop testing or denies testing for product
• When the outcome of testing will not change the decision of stakeholder
• When no information is expected out of testing
• When a tester or stakeholder feel the outcome of testing being carried out is not going to help in making decision
• There is no area or question in the product for which testing helps to see an answer
• When no one is interested and curious in outcome of the testing

It is business and business is also on money and time. As a tester it is my responsibility as well to help make decision when testing is not needed and when not to test. For doing this, I need to build the credibility with stakeholders.

However, as a tester, I continue to uncover risks if that really helps stakeholder and if I'm sensing it from my testing. While this is being done, it is also good to note, time of tester is also important as it is value and money. If I think my investment on time is needed here, I will do it, provided I see a good cause and benefit there.

Did that help now in context free way to decide when to start testing once the build is available or yet to be available? Further, build the contextual reasoning to figure out when to start, when to stop and no need for testing when there is a situation.

Why the 'Garage'?

I got a question while talking to one my friend and colleague, why the 'Garage' and 'Testing Garage'? I was thrilled hearing that question. Four years back, I asked for meaning of a word and why this product is called by that word. And that product was in market for almost 3 years i.e. before I started my professional testing career. Today it is getting sold successfully probably bringing good revenue. Finally I did not know why the product was called by that word and what it meant. Later I got an opportunity to meet the global technology chief of the organization of that time and asked him the same question. I did not get an answer except saying "It does not have any meaning." which in turn made me to ask "then why that name?” Let me stop this here. The same with software products I have tested so far, most of the time I did not get answer why was it is called by that name. I do not want to assume myself what that name mean without knowing the actual one, and why it is used; you see the testing begins right with name of the software product being tested and knowing its purpose of existence and for whom, with a question "why should I test this?". Hope you know now, why I was thrilled when my friend asked me about word ‘garage’ in Testing Garage.

Back to garage, Testing Garage. My father repaired his cycle and I use to watch sitting beside him. Near to my home, shops usually called 'cycle shops' that repaired, serviced, rented and sold the cycles exists. Still my father use to repair cycle for himself. I use to ask him, are you a mechanic while he removed parts of his cycle. Today he repairs his scooter for himself most of the time and I keep watching it.

Now what my father did was few observations or inferences while riding his cycle or scooter. He felt something unusual; maybe he compared and evaluated the differences. Inferred something is not as expected or unusual from how it was or how it should be. Later he continued to evaluate with experiments then made a decision what actually the problem is that brought in the differences. What he did here was 'Testing' and while he fixed the problems he thought how this may cause difference again. But whatever he did to fix difference, it gave birth to new differences or brought back same differences gradually.

After seeing father repairing the cycle I wanted to see how big vehicles would get repaired. I went to garage with my father which use to service ambassador car and scooter. I saw the mechanics heard the words of customer and started to look into the vehicle asking questions to customer. Again here what mechanic did was not just comparison, but evaluation too.

I made few common observations here. Both my father and mechanic used tools when needed and they used their ears and senses together with replies of other concerned people to know what they are making out. Tools were used when needed and they were spread out on the floor in garage. Father asked me to pedal cycle and use to watch the differences before and after fix. At garage mechanics use to analyze and talk to each other and one use to say this is the problem; probably maybe he was a chief mechanic there at that time. At home father talked to me while repairing the cycle. We shared and my father trusted my words and questioned while I pedaled cycle. In garage, mechanics and customers communicated about the problem by trust with questions to each other and customer who had a concern.

An interesting observation what I made is, father used same tool for different repair and also said that to his friends in repairing their cycle. Looks like I made similar observation with mechanic in garage too. They invented new ways of using the same tool when they needed it. To repair a cycle the tools used were not just made of metal but things like stone, a broom stick, piece of cloth, a rope etc. were used as tools. Garage too had such tools apart from metal tools. Things available around us were used as tools depending on the situation while the cycle was repaired.

I was attracted by this for:

• Working in pair when required amplified learning, problem identification and solving skills. This was evident for me in garage and repairing a cycle at home.
• Brought new radical ideas while fixing the problem in the conversational talk. These ideas brought primal changes sometimes which satisfied the customer or concerned person.
• A skilled mechanic had an objective to know the problem and to fix the problem; focus of mechanic on this was evident.
• A mechanic evaluates and assesses his or her progress while servicing and make sure that expected is being carried out.
• I figured out skilled mechanic using strategies with a plan, while trying to know the problem and/or cause of the problem in a vehicle.
• Mechanic relied upon human skills rather than thinking or saying this cannot be done without a tool. Existing tool or things available around were reinvented as new tools. But tool alone did not do task; a human was needed to do the task and analyze it. Tools helped mechanic to make the job bit simpler.
• Previous experiences and relative knowledge or information of other repair and problem which is not related to garage or vehicle, was used in evaluation before repair and after repair on comparison using as reference.
• In garage, reference point or reference source(s) or history of earlier services, played a role in assessing the problem that can come up from service given.
• At some point the assessment was done just to fix the difference that was seen in vehicle or cycle. But there was no further work or brain bite to know what other problems may persists or may come up, except the checks and tests made for the repair done or service given for then. This was obvious from work and to be noted here.
• But to identify the existing unusual difference or problem in vehicle or cycle, investigation carried out was interesting to me. This investigation had several tests and not just checks from comparison or reference source.
• Environment in garage was maintained every day to attend the customers who came up with the (different) problem and different vehicles.
• Detail of what the problem was and service or fix given to vehicle, was said to customer.
• In short, mechanic worked technically to provide information and a fix for problem(s) that was known or unknown for concerned person(s).
• Sometimes decision of mechanic worked. But the final word on quality of work was from customer. Decision at last is in hands of concerned person or customer. Noticed that words of skilled mechanic influenced decision of a customer.
• Looks like problem or risk was for a person who used a vehicle. But that problem could bring threat to others too on roads. Hence problem cannot be denied with vehicle here as how we cannot deny a problem in software application.
• In a skilled mechanic, I saw a tester who tried variations by questioning customer to know the problem(s). Though mechanic tested the service given for vehicle, it did not stop problems coming up.
• In garage, customer defined “Job well done” on using the vehicle which was serviced by mechanic(s).

Relating mechanic at garage with a tester testing software application:

• Skilled tester will have an objective or goal of testing, while testing.
• A tester evaluates her or his progress while testing and evaluates that with the objective of testing.
• A tester makes use of strategies to bring out effective tests that justifies the objective of testing.
• Being a tester when I worked by pairing with other tester or people, I learned and observed much more. This improved in identifying the problem and issues.
• The lab, desk and thoughts of tester will have several tools along with tester.
• I observed testers using tools to help their testing and analyzed the work after using the tool too. This was very same with mechanics in garage.
• Each tester evaluated response or behavior of software application, based on comparison using a reference source or point. Later application was evaluated to assess probable problems in using it. It was interesting to see how the problems of other fields brought ideas to test software application upon relating them.
• Lab and test environment was maintained to identify the problems that are not so obvious or easy to identify. Also lab or test machine was maintained to simulate the problems that customer brings out in an overnight.
• Investigated to find the probable cause of the particular known problem and its symptoms.
• Tested to assess the problems after fixing the existing problem and its symptoms.
• Test report gave the coverage and observations made during the testing for people who are concerned about the software application.
• Tester conducted investigation to assess possible problems underlying or unknown or known for making better decision by concerned people.
• Decision was made by concerned people and not by tester. Information from tester influenced decision of concerned people.
• Whatever the test and coverage was achieved with modeling, problems still come up in software.
• Customer defined how the product is and said “Job well done” by TEAM, on using the software.

Likewise, I can make several relative things in a skilled mechanic working at a garage and a tester testing software. Hence I keep word ‘Garage’ with word ‘Testing’ which reads as ‘Testing Garage’.