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. :)

Who Talks About Your Work?

You talking about your work is stronger than the work talking about it.  Why?

I see, the work speaks in terms of change it brings -- the feeling and emotion of other people.  In the change, people do not see you.  The people see themselves and it is not wrong.  People see how your work made them feel; not what you feel for giving that delivering work.

How you are feeling, what you are feeling and what is that you are expecting for doing the work -- you should make it explicit and talk about it.  I see this is fair ask, be it at home or at business.  

In business, you are paid for the work.  That is how the business looks at it.  Probably nothing more than that.  If not you, someone else will come in to do that work.  But, then what is the difference in you doing and someone else coming in and doing it?  How do you put this across and persuade with an influence?  This is, you talking about your work and presence.  This matters!

At the bottom, everything has calculations -- at home or at work.  One has to talk about her or his work, presence, and value.  This is a useful lesson for family members at home and peers in work place or community -- which is not spoken or taught in school and home.

It happens that, people talk about you and not about your work.  Then who will talk about your work?  You talk on your work.

To open you up to talk about your work, 

1. To talk about your work, work and know your work
2. There is a thin line between bragging and talking about your work
• When I say talk, it is communicate -- communication
• How do you communicate about you and your work?
3. Talk about your work with,
• Data that can be correlated with change and growth
• Quantify it
• Change and growth is well received when it is quantified
• Illustrate this with data which is evident and interpretable
• I said, evident and not logical; logical does not resonate always
• Change, Impact, Consistency, Influence, Trust, Value
• Highlight the trust and its consistency from your work
• Reliability
• Challenges remaining
• Gains and loss
• Talk about loss which are competent gain
• Changed and unchanged
• Continuity -- how and why
4. Your gain and loss is not just your work, it is also what you talk about your work
5. Know your ego when you talk about your work and others work
6. Before talking about others work, know your work and talk about it
7. In short, talking about others work is -- What you are not doing!

If you do not talk about your work, neither your work nor others talk about it.  Never!

Talk about your work!

Testing and Programming Are Not Separate Disciplines

 

Do you and your team see Programming and Software Testing as two separate disciplines?  You believe that programming and testing are as different as oil and water?   If so, this blog post will converse with you to realign your thoughts.

When I started to draw the correlation between Software Testing and Programming,

• That is when I realized Programming is beyond writing the code.
• Testing is an integral part of programming.
• Writing code is one part of programming.  
• Likewise, testing the written code and the associated system, is part of programming.  
• I see, the idea of TDD is an example to it.
• Testing is not the other side of a coin.
• Programming and Testing are on the same side of a coin!  Testing helped me to learn this.

Then, what is on the other side of the coin? 

• It is we on the other side of the coin, 
• Who are seeing and advocating testing and programming are the two different disciplines.

Had I understood this early in my career, it would have made a significant difference.

For the last 10 years, I have been assisting myself and mentees to experience this perspective of programming and testing.

The sad part is, the colleges and universities do not tell this to their students.  Instead, we are said the programming and testing are two different stuffs in software system and engineering.  Thereby, treating the one is superior to other.  Eventually, we in the industry continue to share the same thought and dialogues in all spaces.  Thereby, creating the gap in skills and thoughts of both programmer and tester.

Programming 

What is Programming?

A program is planned and an ordered event of actions with a purpose.  When it is ordered in a specific way, it involves logical decision of a programmer to design and implement a program in a intended way.  

In Computer Science, I accomplish this with the help of programming languages and commands which an operating system leverages and executes.

Programming is a thought process and thinking activity which evolves over the time with discipline and consistent practice.

• It involves thinking, understanding, questioning, and analyzing the intent of learning and solving a problem in hand.
• It demands questioning and learning the context.
• It involves studying of -- systems, people, environment, communication, programming languages, design, modeling, simulation, engineering, technologies, anthropology, geography, economy, business, politics, laws, regulations, computer software, software tech stacks, hardware, domains, different professions, jobs, emotions, crime, psychology, science, arts, and you can add more to this list as you unlearn and learn.
• It demands analytical thinking, critical thinking, and ability to develop clarity for making decisions to design the implementation and code.

Programming is like a manifest file in Android app, where it manifests and expects how and what the app should be like.   The app code implements the manifestation.

Coding

Visualizing and writing the programming instructions from the manifestation thought of programming is coding.  The programming instructions [logical] are written using programming languages.  I understand it, this way.

To code, one uses programming languages.  Further one has to understand the Data Structures and Computer Hardware and associated software to code efficiently and effectively.  This is where I understood the need and value of the Data Structures.  This forms the basic and fundamental necessity for one who wants to build and test the software system.

Each programming language has its own,

• Syntax
• Rules
• Limitations
• Way of execution
• Space
• Time
• Storing and retrieval of data

The below said will be well evaluated for the context,

• Which programming language to code? Why?
• What Data Structures to use for processing the data?

That said, the idea of debugging remains relatable and same in most cases irrespective of the programming language.  

That is, the debugging is at meta layer of programming.  Based on the context, how the debugging is done, can change with the programming language.  But, the idea of debugging remains the same.

Programmers learn and practices different programming languages.

Programmers solve the problem using programming language.  To solve, programmers start visualizing with programming, and then code.

I see, the programmer learn -- Is the actual problem being solved?  So that the time and efforts are well spent.

To stop here, there is,

• Clean Code, and not Clean Programming
• Code Smell, and not Programming Smell
• Code Refactoring, and not Program Refactoring

Programming and Coding are two different skills and it runs in parallel helping each other.

It is like, the programming is a blue print, and, coding is the construction work.  Both are needed!

Testing

Having one's own definition as a practitioner is good.  But, then I see, my definition also aligns with that of Dr. Cem Kaner, James Bach and Ashok Thiruvengadam.  So, I quote their thoughts here.

Testing is,

• Questioning a product to evaluate it.
• Probing the system to learn and evaluate it.
• Empirical technical Investigation
• To learn quality related information of a software system
• So that the stakeholders can make informed decision

I see, testing is an another stand to the programming.  It is not different.  

Programming and Testing are analyzing and thinking skills for first.  The thinking applied and implemented and evaluated is coding skill.

What all needed for better programming, all those are needed for value adding testing.  Refer to the above section on Programming.

Further, testing uses coding to execute the intent of a test to some extent.  And, this is a need.  Being skilled in programming and coding gives a different perspective and strength to the testing.  The value out of this will be distinct and prominent in most context.

If one can test, one can program too.  

Now, do you see that the programming and testing are not the two disciplines?  They are one!  They are on the same side of the coin.  On the other side of a coin, it is we who are not willing to see this and advocating these two are different.  

I learn, a skilled tester can add keep adding ways to sample, interpret and test when she or he can use the coding skills.

To summarize,

1. Programming and Testing are the same discipline.
• Seeing it as two different discipline is counterproductive!
• This counterproductive can be seen in the software industry, today.
2. It is useful thought process, mindset and attitude to see both programming and testing as a overlapping areas and one discipline.
• Both are on the same side of the coin in Computer Science, Software & Engineering
3. Coding skill does not mean one has programming skill.
4. Coding skill does not mean one has testing skill.
5. Programming skill shows the testing skill and vice versa.
6. Programming is a way of testing.
7. Programming is a way of debugging.
8. Testing is a way of debugging and refactoring the programming.
9. Programmer develops the tests and code.
10. If you can program, you can test.  If you can test, you can program.  If you can program, you can code.
• But, coding skill alone is not enough to program and test.
• These all are three distinct skills, where programming and testing overlaps very much on each other.

Software Design Principles in Communication of an Engineer

 

As a reporting manager, anytime did you say this to one of your team members?

• You did not deliver what the organization expected.
• You did not deliver what the business expected.
• You should also deliver what the company needs; but, you did not.

If you hear any of these from someone in the team other than manager, it is more likely, the story is narrated in the team, and you are hearing it now.  How to avoid ending up here?

Reporting Manager and Communication

When I'm in the role of a reporting manager, I want to avoid the below mistakes and keep my team well aware and informed.

I see, most of the skilled engineers are put to a corner because of not good communication from the reporting managers.  And, not all engineers are aware of politics and to move politically.

I listen and converse to such engineers. They are not well communicated and aware of -- what is expected by business, company and stakeholders.  It is not communicated in precise and straight.  

But, it is expected from one to deliver. Failing to do so, the message narrated to the floor is -- she or he did not deliver what is expected.

When I work in the role of Engineering Manager or Director of Engineering or its above roles,

• One of primary responsibilities is to be better in communication day-by-day and follow the KISS - Keep It Simple and Straight.
• Yes, you read it right, it is KISS.

How are you communicating in the role of Engineering Manager and Director of Engineering?  How effective, simple, precise and straight it is?

Software Design Principles and Communication

Communicate with your engineers in the teams.

Help your engineers to understand the expectations.  Practice the software design principles in your communication.  Give it a try!

If a software engineer can identify and implement the design principles in the software she or he builds, then, she or he can identify it in your communication and the expectations you have.

These software design principles should be in our communication day-on-day,

1. KISS
2. DRY
3. YAGNI
4. TDA
5. SOLID

Do not have these design principles just in the interview rounds and sometimes in the code review.  It should be in our communication and day-to-day decision execution.

Do you have these in your communication?

Or, just in the interview you take and the system you build?

Ask your team member if she or he knows your expectations.  Ask, how well you have communicated it.

To sum up and summarize,

1. The team or a team member is skilled but failed to deliver the expectation is more likely when the expectations are not well communicated by her or his reporting manager or the skip manager. 
• The other case is, the engineer is lousy and not stepping up.  But, most times it is not well communicated.
2. The Software Design Principles as KISS, DRY, and YAGNI are not just for the software we build.  
• It is also a must practice in our day-to-day communication and engineering's decision execution.  
• If it cannot be practiced in our communication, I doubt, if a team or org practices these design principles in the software system it builds and ships.
3. The reporting manager role is underrated and not understood well enough.  
• It is one of the critical roles in the business and org.  
• Any of us can be a reporting manager in role. But, hardly a few have the lasting legacy of being the effective and efficient reporting managers.
4. Communicate it straight and in simple, so that, each in a team knows her or his objectives and how it will align to business's goals and objectives with an impact.
5. Learning to deal with one's ego is a underrated and unspoken skill.
• Foster and build culture where one approaches you with questions to seek clarity.  
• When you demonstrate how well you are handling the ego, the other can spot it and will manage her or his ego.  If not, still you will master your ego!
6. Like, how a child's growth behavior is reflection of people around it, an engineers growth and behavior is a reflection of you and people in the business and org.
• The reporting manager's persona, communication and character will leave the marks on team members and org.

Happy Engineers Day!

Empathy - Missing in Engineers. Then, Why Think Like a User?

I did not know about the word 'empathy' in English.  I heard it for first time 15 years back.  This does not mean, I did not have or express or share the empathy.  

We engineers talk about empathy to the users when building the software.  That is, think like a user.  If you are a test engineer, testing, then you should have heard this.  And, you should have asked yourself -- "How will the user feel with this?".  Did you?

When you write a bug report or any test report, you think and ask yourself, "Can this be easily understood by the reader?".  Won't you?

You are having the thought and an emotion of empathy in that thought and question!

How's the Empathy of Engineers for Engineers?

Anytime, you asked these questions to you?  What do your voice say?

1. Do I truly listen to my colleague and peers?
2. Do I document?
• How well and lean I document so that fellow engineers can use it?
• Can they use it in my absence?  Does it serve?
• For example, 
• How well I name the variables, so that, someone who is reading my code can make sense out of it?  This is empathy to your colleagues.
• How well I write the test engineering related testware, so that, it serves my fellow test engineers and others?  This is empathy to your fellow testers.
• Before thinking like a user, think -- How my fellow testers feel for using your work and communication?
3. Do I consider how my words and behavior affect the people I work and collaborate with?
4. Do I listen and respect my colleagues and peers view while I discuss and share my perspective when it differs?
• Am I ready to accept the same treatment and communication that I share with others?
• Do I share and communicate my perspective and intent for first?
5. How do I interpret other person's understanding and thought about a subject, work and practice?

If you are a programmer, 

Ask yourself when and how you respected your fellow programmer and testers thoughts and work?

If you are a tester, 

Ask yourself when and how you respected and listened to your fellow testers word and work?

If you are a manager or director or VP or CxO role person for engineers, 

Ask yourself, when was the last time you listened and tried to understand the words and thoughts of your programmers, testers and other roles?  How did you listen and communicate?

• How did you help your teams and a team member to understand your point?
• Did you consider one of your team members as your team?
• Did you say anytime, she/he knows better than you, to any of your team member?
• Did this end or impact the communication thereon between you two?
• Further, ask yourself and list out the incidents that you could have avoided a situation and communicated well with dignity?

It is easy to say the slogan, "Think like a user".  

It is much easier to say this to your testing team.

But, it is not easy to think from the point of your colleague or peer.

Why?

What stops you?

Empathy Starts Within - A Message to Engineering Leaders

As leaders, we often say,

"Think like the user."

It is a powerful principle.

But, here is the question.

"Do you think like your engineers?"

You hired your engineers by conversing with them.  What are your efforts to make your engineers understand your thinking?  What's your principle on this?

If you cannot think and respond to the point views of your colleague or peer or team, how can you think and build the software system for a user?  Yet, say from decades, "Think like a user"!

Let me ask this.  Anytime, you tried to impose or overrule the testing team's thoughts, pain, voice and perspectives?  Or, did you talk to them to understand it and then shared why it should be the way you are deciding?  

Did you think as your test engineers and test team?  And, you want them to think like a user?  How?  

I'm not saying to agree and acknowledge to whatever the test team say and ask.  But, are you aware that, you work with test teams?  They are one among who consumes your decisions and work to deliver as a team.   What's your empathy to them?  Also reflect on what's your empathy to other teams?

If you cannot communicate well and help them understand your points and need of the business, then, how effectively as a team can we deliver value to the users who buys the service of the business?

When no empathy to fellow engineers on the team by an engineer, and, by the one who is heading the engineering teams, how can one have and express the empathy for the users who buys the service of the business?

Do you have the empathy for the engineers in your team?

Do you have the empathy for the teams you lead?

What is empathy?  What is your empathy?

I understand, in the business and with an executive role in business, empathy has scale.  What's your empathy scale for your engineers?

To end here for now, before the users, let your engineers and teams experience your empathy.

 

Give a Name for the Base64 Image in an Extent Report

 

I read the below question in Testing Mini Bytes community.

Hi All, I am using extents reports in my c# automation framework. I am trying to attach the screenshot but it is always showing with name as base64img. Any idea how to overwrite that base64img to customised text?

Capturing a Screenshot in the Test Run

With the Extent report, one can capture the image of screen during the test run.  This capture can be on certain condition or state being met.  That is, it can be -- on fail of a particular action; in a transition between the states; etc.

In an Extent report, when the image is captured as Base64 image and the thumbnail is set to false, the images captured will have name "base64img".  Clicking on this, I see the respective image.  

No Customized Text as Name for Base64 Image

Say, a Extent report has 10 images captured as Base64 image with thumbnail false.  All these 10 different images will have the same name -- base64img.

• This can be more chaotic to interpret when a test run has captured more than one Base64 image, and, all have the same name -- base64img.
• Do you see that? 
• How do you know what is that image without opening it just by reading base64img?
• That's hard and you have to make additional clicks to know what is in each image!
• Is this a better use of time of you who is reading the Extent report?

Naming the Base64 Image in an Extent Report

I see, the semantics in C# should also be similar to what I'm sharing below.  

The above gist should help to have a customized text given for each captured Base64 image.

In this case, the captured Base64 image name will be the customized text "Resend_OTP_Button_Not_Available" and not base64img.  This makes it more contextual and relatable for the reader of an Extent report.

Monetary Value Round Off -- A Legal and Business Problem

 

I read a blog post from Gaurav Khurana suggesting on round off of a number having decimals.  This is the post.  What made me curious is that number and what it meant.  It was a discount money having decimals.  Here, the number of decimals was not restricted to two.

Gaurav, said, it is a better experience if that discount amount is restricted to two decimals and rounded up.  Initially, I see, this is a fair expectation.

Here is the pic of a bill which Gaurav has shared.  I'm using it here on his permission.

I woke all of a sudden at 2:18 AM today, and I relooked into the post and that value whose decimal is not restricted.  I said myself there is something which cannot be rounded up or rounded down here and I could interpret it for a context.

Interpretation of the Value and its Meaning

1. The "Bank Discount" showed the below amount
• - 450.90999998999996
2. The amount is in Indian Rupees
3. This amount tells, it is the discount offered by the Bank on that transaction
4. On round up, it will be,
• - 450.91
5. If I use the round up value, then the "Balance Paid" amount will be,
• 4,058.18
6. If I do not use the round up value, then the "Balance Paid" amount is still,
• 4,058.18
7. If I do not use the decimal values in "Bank Discount", then Balance Paid is,
• 4,059.09
• That is, I will have to pay 0.91 rupee (91 paisa) more.
• In this case, someone is at loss.  Who?
• Business?
• Customer?
• In the context of this bill, it is, customer who is paying.
• Customer will pay 91 paisa, which is, almost one rupee more.
• Now, imagine, the profit which business makes from all its customers for not having that decimal values in the amount!
• Is this right?

The meaning and value of Balance Paid is not affected, in both cases, that is,

• When I use Bank Discount value as is with decimals.
• Or, When rounded up with two decimals.

My question is,

We should have check on decimals shown and used.  But, should we round up the number when it is of monetary significance and value?

Why I have this question?

• Refer to the below examples.
• 450.35
• On round up, it will be 450.5
• 450.55
• On round up, it will be 451

If observed, on round up, the amount discounted is in excess by 0.15 rupee, that is, 15 paisa; and, in the case-2, it is in excess by 0.5 rupee, that is, 50 paisa.

If the bank loses these paisa for each transactions of same customer and other customers, won't the bank is shelling out the money?  Is this good?

Likewise, if I have to pay 0.15 paisa and 0.50 paisa, am I not paying more?  Then, imagine the big amount that business is making by rounding up a monetary number and making its customer pay in excess.

My Thoughts on Monetary Value Round Off

1. The monetary value should not be rounded up or rounded down.  
1. But, it can have a decimals and limited to two or to what business sees manageable.
• As Gaurav said, decimal to two digits makes life easier for all is my understanding.
2. The customer need to see this monetary value.
2. The generated bill or transaction should have this detail.
3. When making a payment, the billing system, can show a round off value.
1. And, the business should decide upon, should the amount be round up or round down

May be to avoid such arguments and discussions in the billing counter, today, the bill amount will be a whole number and not a number with decimal.

Such round up instances can turn to a legal problems for the business.

I have noticed, the business offering round down on a monetary value, at times.  Also, I have noticed, certain consumer mobile apps showing rounded up number without breaking down the bill details.

Whatever, as a Test Engineer, I and you, have to create a report [ticket] for product's reference; keep the stakeholders informed of such behavior in the system by explaining the impact to business in monetary and legal aspects.

Solution Approach - How to Automate to Use the Magic Link for Login?

 

The question asked in The Test Chat community on 14th June 2025 22:42,

Hi All,
Has anyone implemented test automation for an application that uses a magic link for login?
If yes, could you please share the approach you followed?
Thanks in advance🙏🙏

My Analysis and Understanding

1. The question asked is around automation.
2. That is, how to automate to use the link (hypertext) generated for login.
3. There are several ways to approach this, via
1. GUI
2. API
3. Combination of GUI and API
4. I prefer to use it in combination of GUI and API for first without using any email client services and app.
• Why?
• I want to keep it simple, quick and not to complicate the testing problems much more.

Solution and Approach

I see, it is not a complicated Test Engineering problem unless the project and floor do not support.

I understand, it is about using a link (hypertext) to login into a application via automation.

How do you get this hypertext?

• It should be generated somewhere within the system's boundary.
• Can you get that generated hypertext without using any mail client and its service points? How?
• Do you have an endpoint that generates this hypertext?
• If so, then this endpoint should also have some means to share the generated hypertext for login request?
• Pick this generated hypertext via an API request in your automation.
• This should work!  Unless the test goal in the automation is not to open some configured mail client and read the received mail.
• But, how many times will you do this in automation, if the goal is to open configured mail client?
• Is this a good use of automation?

If there is an endpoint to GET that generated hypertext (POST), it is a fair simple task.  

Say, there is no endpoint with GET request to give the generated hypertext. Then, look at the response payload of POST request that generates the login hypertext.   Consume this hypertext now and use it in GUI automation to login.  Say, there is no response payload in POST request.  Ask your team to build a GET request to consume internally and maintain it securely so that no external access is allowed.

Let us keep the testing problems simple!

 

Solution Approach - Blog Posts Series

 

I read questions and challenges shared in the Software Testing communities.  I try my best to assist in the ways I can.  

While I do this, I share the solutions and how to approach the solution.  

• I see, this solution approach is good to be here as well.  
• So that, it can serve as a reference to the readers who come to Testing Garage.
• To make this happen, I will be sharing the blog posts with the question asked and possible solution to it, under the tag label "Solution and Approach".

If there is any follow-up discussion by the community and the person who asked the question, I will share those detail in the comment section of the same post.

It will be a simple and quick read blog posts for you, most times.

Have a good time reading, analyzing, debugging and challenging the solution and approaches I share.

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!  

Browser Compatibility - What Problems Are You Witnessing In 2025?

 

One of my long standing work in Software Engineering is testing for Browser Compatibility.  But, is that a bigger problem as it was between 2000 to 2017? 

Today's browsers have to and adhere to the common guidelines and standards of W3C.  Likewise, the web development and artefacts [libraries, frameworks, language, etc.] used are expected to adhere the standards and guidelines.

In 2012, I layed out the evolving model of Test Architecture for Browser Compatibility.  The teams across Aditi Technologies did use this solution and it evolved gradually.  It is the 'go to' test solution and approach to test and automate for web application's browser compatibility, strategically.

Those were the days, where the browsers and web development did not adhere to standards and guidelines.  As a consequence, the web pages exhibited problems and unexpected [intermittent] behaviors on major browsers and its versions.

I understand and aware, that, the browser compatibility behavior can be a GUI difference to a functional blocker.  Further, it can expand to the web page's performance behavior to accessibility and security differences.  I have witnessed all this when testing for the web application and its browser compatibility, then.   

I cannot forget the versions of Internet Explorer crashing while another did not when using the web pages.  

Maybe, on reading this, you are thinking of me as an old tester.  Is it so?

2025 and Browser Compatibility

I'm curious to know and understand from you.  So, I ask this question to you.

Did you experience and report the browser compatibility behaviors recently?  If so, what is that?

Please do not share the project and tech details.  

Requesting you to share what behavior did you notice as part of the browser compatibility and which quality criteria of the web page is impacted.

I'm one ping away on Google Hangout and on an email.  Please do share!  This will help me to contribute back to the Software Engineering and Testing community.

Are We Not Innovating, Then?

 

This last Sunday, I met a friend.  In our conversation, he brought up a topic between him and his colleague.  

He said, there is no innovation happening in Software Engineering.  Instead, he see the apps development to cater business services to people.  That is, in other egineering industries there are innovation being done along with research and development.  But, he did not see anything happening in our Software Engineering and communities.

I asked him, "What makes you not to see the Hackathons [being projected] as an innovation initiative followed up with further research and development?"

He did not see the hackathons as a space for innovation.  His experience is, the organization hosts Hackathon for two or three days in a year.  

Further, he said, "We are asked to participate in the Hackathon and also to work on stories in parallel.  If the stories are not worked in these two or three days, it will be escalated.  And, the ideas and outcome of the hackathon are left as is.  Hardly one or two ideas are picked for a proof of concept work in the project."   

I feel, maybe, what he is saying make sense, as I have witnessed it.

Are We Not Innovating, Then?

I see, there are innovations happening in the Software Engineering.  But, these innovations are not something that common men can consume directly.  But, these innovations are consumed indirectly by the common men.

The innovations that I see and test are not B2C.  Sometimes, it is indirectly B2B via D2D.

Yes, D2D -- Developer to Developer.  I'm not sure if there exist a word Developer to Developer.  This is what I said to him -- D2D.  Maybe for this reason, the innovation and software engineering's problem solving and solutions do not come to the discussion and spotlight.

As an innovation byproduct in the software engineering, there are frameworks, libraries and artefacts developed by the developers of an org [and communities].  This is being consumed by the other organization's developers in their project.  As an outcome, there is a solution being built [using an innovation] and delivered by a business which is consumed by a common men.

Maintaining these frameworks, libraries and artefacts outside the payroll job time is a challenge for any developer.  But, some do it beating all the hurdles they experience.  There are challenges here when it comes to maintaining such projects by collaborating with software engineers from the communities.

Most of my research and development outcomes in the Test Engineering area are consumables of we developers and not the common men.  And, it is not known to all the  developers.  When I say developers, it includes, programmers, test engineers, DevOps and product teams.

To conclude here for now, might be the software project you are working on is also consuming an innovation that you are not aware of.  Talk to your programmers, test engineers and teams.

AMYQ: Approaching the Solution to Test Data Challenges of Shrini Kulkarni

 

In this post, I'm trying to reason in brief for the questions shared by Shrini Kulkarni in this AMYQ.  Here are the challenges/questions shared by Srini,

• #1 challenge - setting up data in upstream systems to suite test cases that need to be run. There is AUT and there are upstream systems. In a corp setup -- individual teams are setup for each application. Hence getting another team to set some data in other system often encounters lots of manual effort and red-tapism

• #2 Reserving test data created in AUT or upstream systems for specific team's use so that other teams do not change it.

My Understanding of These Challenges

1. AUT is in place and it has upstream systems.
2. There are multiple teams for each AUT in an org.
• Say teams A, B, and C for sake of learning here.
3. Team A has difficulty when wanting to create the Test Data in the space of Team B, and vice versa.
• The difficult for Team A can be as,
• Not permitted to create data
• No awareness and understanding of Team B's system
• Cannot make progress in testing unless there is data created for Team A
• The created Test Data by Team B is not shared to Team A for multiple reasons as data pollution and corruption which disturbs their test cycles
• And, more ...
4. How to reserve Test Data created in Upstream system for use of a specific team?
• How to make sure other team does not use it or edit it or delete it?

This is my understanding of Shrini's challenges.

Conway's Law and My Experiences

The Conway's Law says,

The architecture of a system will be determined by the communication and organization structures of the company.

Inverse of Conway's Law says,

The organizational structure of a company is determined by the architecture of its product.

The above stated both laws hold good for Microservices teams and the teams which consumes their services.  

I have experienced,

• Each microservices teams creating their own set of test data.
• These test data is not shared to any other team.
• The other teams are not allowed to create data in their space.
• No team is aware of what others are doing in tests and what they are using to test.
• The teams work in silos.

This leads to friction, aggression and unhealthy communications between teams.  Now, where is the possibility of having the Test Data in upstream system which can be consumed to run tests by every other teams?

Do you see the statements of Conway's Law and Inverse of Conway's Law here in how these teams are setup, orchestrated and communicates in building one product?

What's the Problem?

Here is my understanding of the Problem Statement from the challenges shared by Shrini,

How to setup Test Data in upstream system, to suite the test cases, that need to be run?  And, how to ensure Test Data created by one team is not modified by other teams?

If observed, the outcome described in previous section is not a technical problem.  

It is the collaboration and communication problem, that comes up in presumption -- other teams using one's test data it affects their team's work and delivery.

Yes, it can impact badly if the creation, editing and managing the test data is not done attentively by teams when everyone shares and consumes it.  So the respective team's engineering managers and directors show the resistance to create data in their team's space as it impacts their pipeline and delivery.

How I Solved It?

In the contexts where I work, I have different upstream systems to which I'm supposed to interact and get the data.  Then, use these data to test the service offered by the product.

But, creating test data in other team's space is not allowed!

There are multiple solutions that I approached with and solved this problem in different organizations.  The below said approach worked with most clients and so I share it here.  It is like a Design Pattern; I can use the structure of it in multiple teams to solve the similar problems.

I came up with an approach to create a suite having the endpoints of all these upstream systems.  And, I need not say how difficult and pain it was to get the endpoints and its details from teams.  It was a marathon circus of me to get it!

Here is how I approached the solution,

1. I understood my teams were comfortable with Postman.  
2. For this problem solving, I see Postman was simple and quicker than writing a automation project with libraries like RestAssured and request.
• Team can run the Postman Collection from their system in quick time.
3. I created an Test Data Inventory
• The inventory has the Test Data which the test teams engineered for their testing and automation
• These data is not just for functional testing; it had Test Data for security, performance and accessibility too.
4. I built the Postman Collection having the endpoints of these upstream systems.
• The collection is version maintained like any other code in the organization.
• The meaningful commits are being made and pushed, as and when the need comes up.
5. I crafted an environment file and wrote the scripts which places a variable having the stamp
• This stamp tells, it is a test data created by automation run for this version of regression cycle and from this team.
• The stamp is max of 10 characters and it is dynamic based on that run to avoid duplicate data.
• I said it is dynamic and not the random!
• This dynamic characters has meaning and an intent.
• Note, when I say dynamic it is created for that iteration of Test Data
6. These created test data are used by team eventually not touching the test data of other teams.

This let us move further with our tests and automation in the pipeline.   Note that, I have multiple upstream systems to which the AUT speaks.  Not disturbing them is a challenge!

I maintain the inventory of test data having versions of test data being crafted sprint-on-sprint.  We pull the test data of different versions from the inventory as and when it is needed for the intent of test and automation.

All that said, the team continues to work in silos with no much collaboration.  Who has to solve this?  Though I can solve this, my role and pay grade does not allow me to do so effectively.  I have solved within my teams and not to the organization level.  It is a engineering and culture problem which has to be addressed at the organization level.

To summarize, 

1. The test data creation and its inventory management having versions of test data is an Engineering culture of an organization.
• It has to be taken in consciously and help the teams move swiftly in building the resilient and usable systems.
2. Test Data and its engineering is a project within an engineering project.
• No wonder if any LLMs offers a business solution solely on Test Data in coming days!
• Test the data offered by such LLMs before consuming it.
3. Practice in the space of test data and testing the test data.
4. There is Data Coverage in the engineering like it has Test Coverage.
• What's your Data Coverage?

AMYQ: Ask Me Your Questions on Test Data -- Session 1

I made an opportunity for myself in this format -- Ask Me Your Questions (AMYQ).  I want to keep it a live interaction as much as possible and I chose a YouTube as an aid.  I'm experimenting it; I will improvise and upskill here it as I move ahead in this.

It is not a AMA.  It is AMYQ format with a topic which I come up listening to community.  In this format, I collaborate and interact with community listening to challenges and problems in their practice and work.  And, working on a solution approach for their context.

I asked the software engineering community for the questions around Test Data here.  I have received a few on LinkedIn and a couple of them in person.  We will be going through them.  

I will share my perspectives and approaches to deal with Test Data on Ask Me Your Questions on Test Data, while I listen to you.  Please join here.

Details of  this AMYQ Session -- 10th March 2025

• Title: Ask Me Your Questions on Test Data
• Date and Time: 10th March 2025, 8:30 PM IST
• Duration: 30 minutes + 10 minutes
• Interaction: Live
• YouTube: https://www.youtube.com/live/cKS71LgwPM0

Questions Received

From Shrini Kulkarni

1. #1 challenge - setting up data in upstream systems to suite test cases that need to be run. There is AUT and there are upstream systems. In a corp setup -- individual teams are setup for each application. Hence getting another team to set some data in other system often encounters lots of manual effort and red-tapism
2. #2 Reserving test data created in AUT or upstream systems for specific team's use so that other teams do not change it.

From Avanti Gada

1. Creating/finding data set to test features built on LLM's. How to test AI tools which were built using LLM's.
• The application are internal to organisation. To take generic example say there is college finder when student searches with certain inputs it looks at Internet and gets all possible options in results. How to ensure the data fetched by LLM are right

From Sukanya Santhanakrishnan

1. What one should keep in mind when the test data is confidential like passwords/person details? How should the system handle this in terms of security?
2. In the AI era, do we rely on LLM generated test data and how much can we believe those? What are the additional steps we need to take after getting LLM's data? 
3. What are the considerations when the applications handling large datasets under high memory usage? 
4. What are your go-to checklist when you start preparing test data?

When Does the Community Choose Not to Respond to Questions?

I read the testing, automation and test engineering related questions posted on the social media and web.  I try to understand the question, problem expressed and collaborate to assist.  I do keep 46 minutes in a day for this activity.  

Sometimes, it is hard to assist reading the question.  I feel like not giving up; but, then I do not see the communication happening actively from other end.

What Makes It Hard To Assist?

The questions asked,

• It will lack the context.
• It does not tell who is the person and what she or he is trying to accomplish.
• It will not have information on
• the environment.
• what is the challenge he or she is facing.
• what she or he tried so far.
• It will not have minimal data as
• screenshot, exception stack trace, the complete error message and details following it, data being used, code outline, and more details to the context.

The above are minimal data needed on removing any sensitive information.  Know and understand what is sensitive information for your context when you are sharing.

Then, what do the question will have?

• Most will have a phrase or a couple or three sentences of what they are doing and what is seen on the screen.  And, asking what to do for what is seen on the screen?

Why it is hard to assist with vague details?

People who want to assist won't have any context about you -- who you are, what you are doing, or why are you doing it that way.  They won't understand your purpose or what you are actually experiencing based on the limited and vague information in the questions.

Without clear details, it is hard to connect the dots or pinpoint the problem.  Instead, people who want to assists will be guessing, making assumptions, and probably considering multiple possibilities.  Is this a way to use the time in community?

When questions follow a similar pattern but vary in challenges and context, it becomes demotivating to decode them.  Over time, people will lose interest in reading unclear questions, leading to fewer responses and missed opportunities for meaningful discussions.

What's happening at other end?

People who want to collaborate and assist will take the time to read the question.  But, when a question is too vague to understand, they often give up.  And, they feel bad for doing so.  The question remains unanswered.

When a solution is provided, there's often no update on whether it worked or not.  Those who contributed keep checking back, only to find no response.  Is that fair to those who invested their time to help?  Would you feel good if you were in their position?

Remember, in the community one can't buy someone's time to listen or solve a problem.  It has to be earned!  And, it has to be earned every single time.

How to Frame and Post the Question?

There is no one excellent way of doing it.  Then, what should I do to post my questions?

1. Know the community.
2. Read through the questions shared earlier in that community.
3. Look at the questions that have found resolutions, acknowledged and accepted.
1. Observe how the question or problem experienced is described.
2. Look at the details shared and how it is shared.
3. Look at the context details shared and how it is shared.
4. Observe how the interactions and conversation is taken forward from the two sides.
1. Closely notice the words and how the energy is kept high in both ends and how each side is pushing for it.
2. Importantly, look at the time taken to respond from both ends.

I do not want to share an example or reference saying this is the way to do it.

You figure out for your problem and to its context.  Share the minimal information said above and ask for the help.  Consistently improvise on how you ask, share and describe the problem.