Payment Transaction Declined With Code 201, Why?

I read a LinkedIn post yesterday.  This post asks for the appropriate contextual message to deal and how to continue upon what is shown to the user.  I see it is fair and straight.  I expect the same.  

Thanks Liudas Jankauskas for writing this LinkedIn post and sharing your experience.

What surprised me is why the discussion was not taken forward in the post.  As a  result, we did not seed the mindset and attitude of Test Engineering and Prevention discussion.  Testing does not prevent; but, the outcome of the test will persuade the prevention efforts and culture.

Okay! If you see this post is too long to read, then here is in short to you -- This is not a API problem.  The API has worked seamlessly and it has done what it is supposed to do.  The code 201 returned is right and it is supposed to be there.  Here, the 201 is not a HTTP Status Code.  It is 3DS Error Response code.

Then, whose problem it is?  To know that, read the entire blog post.  You will thank me and yourself!

I Say This, Before I Start

1. I'm writing this post as an interpretation and analysis for the JSON shared in the LinkedIn post.
2. There is no intention of pointing to anyone.
1. The intention is to share -- how to analyze and have perspectives to analyze when I [a test engineer] experience it.
2. This post can become a reference to someone who is serious about Test Engineering and Prevention, and Testing.
3. The intention of this post is to let know,
1. How to analyze such incidents in the payment context?
2. Is this a API problem?  What behaviors should be classified as an API problem?
3. Which component and layer is supposed to handle it?  How and why?
4. Which other components and layer is supposed to assist to handle it?
5. How to see and interpret the HTTP and its status code in a narrowed cases?
6. It is not always the API problem!
4. I'm open to correct myself, unlearn, learn and update this blog post, when shared why I'm not making sense with I have written here.
1. I will be thankful and humble to you for helping me to correct myself. 🙏
2. Be comfortable and do connect and help me if you see I need it.

The Payment Failed; Could Not Buy Ferry Ticket

The user wanted to buy the ferry tickets by making the online payment.  The payment did not happen and could not buy the ferry ticket.

Instead, the user sees the JSON on the UI. 

The JSON has error description which reads as -- "TdsServerTransID is not received in Cres."

To understand what is TdsServerTransID and Cres, it is required to understand the payment gateway flows.   Continue reading the next sections to know them.

How It Is Layered and Works?

Before I get into analysis and say where the problem is, this context requires an understanding of the payment gateway flow.  Having this understanding, it helps to know how it could have been handled and prevented.

Refer to this below pic.  It gives the sequences of interactions in the payment transaction.  Note that, the below pic is not complete.  It is kept to what is needed to the context of this blog post.

Transaction between 3DS Server and Bank for the Challenge through
POST request.  It is shown as CReq and CRes.

The Sequence of Interactions

1. I initiate the payment on merchant website or app to buy the ferry ticket.
2. The merchant creates a transaction id for tracking.  Then, it hands over the rest to payment gateway.
3. The payment gateway uses the 3DS way to carry this transaction.
4. The 3DS initiates the Authentication Request (AReq) which will pass through the Directory Server.
• The Directory Server reads the data in the request and forwards it to the right bank who have issued the card [or account] used in the payment.
5. The bank receives the AReq.  
• The bank decides should it give a challenge to the user to make the payment or just agree with the data passed in AReq. 
6. Now, in this case the bank has decided to give the challenge to the user.  
• The bank lets know the 3DS server through the response ARes.
7. The challenge usually is to enter the OTP received over a SMS and authenticate.  I presume the same in this case.
8. The user enters the OTP and POSTS the request.  Let us call this request as CReq.  The CReq is sent from from the user's browser or app to the bank.  The user interface on the browser or app at this point is handled by the payment gateway and not the merchant's web or app where the ticket is being brought.
• This CReq will have,
1. tdsServerTransactionId
2. messageVersion
3. messageType
4. challengeWindowSize
5. ascTransactionId
• Note that, the CReq having the tdsServerTransactionId which is generated by the payment gateway.  tdsServerTransactionId is required in the CReq and expected by the bank.
9. On receiving, the CReq, the bank processes the request.  The bank responds back to the 3DS server; let us call it CRes.
10. The CRes will have,
1. tdsServerTransactionId
2. acsTransactionId
3. challengeCompletionId
4. transStatus
5. messageType
6. messageVersion
11. If all goes as expected, the authorization will be given for the payment.  
• If not, the bank responds to the payment gateway (3DS) that there is a problem and the message.
• It is the payment gateway which has to read this problem and message.
• The payment gateway has to give the better contextual information through its interface to the merchant who is consuming the service.
• This is key!
• Hope you found the spot here!

The Code 201 

Maybe, we test engineers presume the error code 201 returned is HTTP Status Code.  Ask your team what is this code and what is the purpose of returning in the JSON.

Back to 201, here.  It is not a HTTP Status Code.  It is neither a custom developed error code by payment gateway nor merchant who is selling the ferry ticket.

This is a payment domain specific code used in the payment technology.  Yeah!  The code to tell the payment gateway and merchant what happened with the initiated payment transaction.  

To be particular and more specific to the context, the 201 here is a 3DS APIs response code.

The 3DS Error Code and its Description.
The credit of this image is to developer.ravelin.com

The above image is shared here so that you know the error codes are available in the payment context.  I'm aware of 3DS protocol hence I could relate and understand the error code 201.  Refer to the References section at the end of this blog post.

The payment gateway has to read this error code. Then provide the right contextual message and instruction to merchant saying what to do incase of payment failure.

Here is the catch.  Not all merchant develops a mechanism to handle this.  Instead, it is left to payment gateway service provider and depend on it.  

Do the merchant bother about handling it at their end? 

• As a merchant, I can switch to another payment gateway tomorrow.  
• Why should I invest in building, developing and maintaining this as a part of my business when I'm paying another business to do it for me?  
• Isn't that senseful business question or decision?

Now, you tell me who is expected to handle this 201 error? Who should let me know on the merchant web user interface what to do?

The Case and My Initial Observations

On submitting the challenge given by the bank, the below details is shown to the user.  

Pic used from the post of Liudas.
It is the CRes returned from Bank to 3DS Server at Payment Gateway.

My Observations

1. Looks like the ticket being bought and payment made was in Turkey.
2. The payment gateway involved to complete the payment transaction is Payten.
3. The user is tryin to buy the ferry tickets and is making online payment. This error is seen on submitting the challenge given by the bank,
4. Looks like the card is used for the payment.
5. In the LinkedIn post, I read, multiple attempts were made to make payment, and the same message is seen.
6. The Error Code returned is 201.
• Which means, a mandatory field is missing and it is a violation.
7. Error Component is S, which probably means 3DS server.
• The component that raised the error.
8. There is an error which is not handled.
• The error reads as Unexpected error.
• There is an id to track it.  That is, for auditing and tracking by the payment gateway.
• This id do not have anything to do with the bank and merchant who is selling the ferry tickets.
9. The message has a version that reads as 2.1.0
• This means, 3DS protocol used is of version 2.1.0
• This is communicated by 3DS server to the Directory Server and Bank Server, so that they use the same version in the contract.
• If the same version is not available at the bank server side, the lower version will be used.
10. Error description reads, the TdsServerTransID is not received in the CRes.
• The 3DS component is raising this error.
• TdsServerTransID means ThreeDS Server Transaction Id
• 3DS means Three-Domain Secure, which is a security protocol used for online card transactions.
11. This means, the response from bank is, it cannot fulfil the payment request.
• Because, the request from the 3DS layer do not have TdsServerTransID.
• Wait!
• Do I actually know if the CReq had the TdsServerTransID in the payload?
• This is critical to know.
• This is important to know.
• The AReq (Authentication Request) will have the TdsServerTransID in its payload.
• That means, this was present earlier.  So, the CReq is fired from the 3DS server on receiving the ARes.
• The bank received TdsServerTransID and said it is giving a challenge  before proceeding to authorization for payment.
• This response (ARes) from the bank will have TdsServerTransID.
• Along with this, the below are also present as a correlation ID to track this transaction.
• dsTransID
• The Directory Server ID to track this transaction
• acsTransID
• The bank server ID to track this transaction
• From here, the CReq payload requires the TdsServerTransID and acsTransID
• Where did the TdsServerTransID go missing now?  How?  Why?
• This needs to be test investigated.  I have shared possible causes in the next section.

The TransactionID of the merchant who is selling the ferry ticket is different from the TdsServerTransID.

• The TdsServerTransID is needed for the bank and Payment Gateway to complete the transaction.
• Without this TdsServerTransId, the bank cannot proceed to authorize the payment.

All this is happening between the payment gateway [3DS server] and the Bank.  The user and the merchant website is not in the picture here.

Why Did It Happen?

It happened because, the CReq from the 3DS Server of payment gateway did not have that TdsServerTransID.  That is what the CRes from the bank says.  

Note that, I presume, the bank systems and services are functioning and serving its customer at this point in time.  This is an analyzed assumption I'm making here and I'm aware of this assumption I have made.

What made the CReq to miss the TdsServerTransID?

1. I read, the user made multiple attempts to initiate and make the payment.
2. I have multiple perspectives and interpretations with hypotheses to say this could have lead to miss the TdsServerTransID.
• Talking about each hypotheses in detail is not the scope of this blog post.
• But, here are some of the possibilities that could have led to this situation.
• A glitch at payment gateway at that point in time.
• Someone is breaching in the middle and tweaking the request and response over the network.
• Device and hardware
• Geo location
• Network and traffic
• Timeouts
• Latency
• Storage running out
• Configuration gone wrong
• Caching and missing -- not persisting
• Intermediate and dependency services clogged
• A new release deployed and updated
• Downtime in the bank's services
• Intermittent bank's services
• Mismatching 3DS protocol versions that is not supported and accepted at either ends
• And, more!

In simple, it was well handled by the bank.  I assume, the amount is not debited from the user's account.  This is equally important and the LinkedIn post do not share about it.

I see the bank's service have worked well in this context and done what is expected out of it.  The thumb rule is, when there is discrepancy in the data expected and received, do not authorize the payment request; abort it. 

Can the service do much more if the TdsServerTransID is missed in the payload of AReq?

Me as a test engineer in the payment gateway engineering team, I will test for the below in minimal and as a must,

1. AReq with no TdsServerTransID and observe how what happens!
2. Do the 3DS server still fire a AReq to the bank with no TdsServerTransID?
1. If yes, then that is a problem!  It should be handled here.
2. This problem can be prevented!
3. I will ask my team why are we encouraging such request?
• This increases our customer support cost and operations time in responding to our clients for using our payment gateway.
• And, merchant can lose the business because of our payment gateway.
3. What should 3DS server do when initiated AReq is missing the TdsServerTransID?
1. What all other data in the transaction and session should be retrained and intact?
2. Will these data change with a fresh TdsServerTransID created?
4. I will explore and figure out what factors caused the 3DS to lose the user's authentication.

Who Created The Problem?

1. From the error shared, I see,
•  It is 3DS server who created this problem presuming the bank and its response is right.  

Is This An API Problem?

1. No, it is not a API problem.
2. If we call it as a API problem, we have not understood what is an API.

Whose Problem It Is?

1. It is the problem of the service that fired the CReq.
• Because, it fired CReq without the TdsServerTransID which is mandatory key-value in the payload.  
• TdsServerTransID value cannot be null nor empty in JSON.
  

It appears to be a business logic problem of the service at 3DS server side for firing CReq with no TdsServerTransID.

How It Can Be Prevented?

1. By making sure CReq will always have a distinct TdsServerTransID.
2. If no distinct TdsSevrerTransID in a fresh CReq being fired, abort the request.
• Create the distinct TdsServerTransID and then construct the request payload before firing the CReq.

To make sure, payment gateway [3DS server] preserves the TdsServerTransID, dsTransID, and acsTransID of the session.  If any one of this not matching at any of the components during the transaction, aborting the transaction is the best and right action to do.  

Can you recall your daily life experience where you are said to not refresh or click on the browser's back button when you have initiated the payment transaction on web or mobile app?  This is the reason!  To preserve the data of the transactions in the session between these systems -- merchant web or app, payment gateway [3DS server], Directory Server and Bank Server.

This is an automation candidate.  It has to be part of the daily test runs in the automation.

Who Should Be Fixing It?

1. In my opinion for today upon analysis and assumption I have made, it should be fixed by the payment gateway.
2. The payment gateway has to interpret the 3DS error code returned by the bank.  
• And, then initiate the appropriate action as the payment transaction has failed. 
3. A new transaction between the 3DS and bank has to be started for that merchant's order.  
• If it cannot happen, the payment gateway should abort all the current open session tied to that merchant's order.
• And, let know the user what is happening, and then direct the user.
4. The payment gateway can read the ARes and CRes.
• That means, the payment gateway can read the HTTP Status Code of ARes and CRes.
• If there is an error code in ARes and CRes,
• Then, the gateway should assert for the 3DS error code along with the HTTP Status Code.
• For example, 
• Say, the HTTP Status Code is 400 and 3DS Error Code 201 in CRes.
• Assert for these two and direct with appropriate contextual message and direction.
• In general, this is how custom developed error codes are handled by the client on receiving it from the services.

Note that, it is Error Code and not the Response Code.  The two are different.  And, the HTTP Status code is different from these two.

Why It Is Not An API Problem?

API is an interface which exposes the available services to the consumer.

It is the services which collects data and build the request payload, and expects the payload to process. 

This request will pass through an interface which is opened to the consumer.  This interface is called an API -- Application Programming Interface.

Analogy,

• The car has gear stick to switch the gear.
• This is an interface to the car's gear system.
• The driver will use the car's gear system through this gear stick.
• The gear box in the car is a service.
• The gear box adjusts and responds by switching to the gear per the driver's input.
• The different operations [business logic] provided by the gear box services are,
• Reverse
• Parking
• Neutral
• Switching the gear and assisting other components to speed up or speed down the car.

Can the interface have problem?  Yes, it can have.  In that case, the service will not be available to serve or to discover.  

• Like, if the gear stick has problem, I cannot use the gears of the car, but, the gear box can be fully functional and in working condition.  
• It is just the interface [gear stick] having the problem and as a result the consumer [driver] is unable to use the services [gear box].

In this case, the payment gateway could fire CReq to the bank.  That is, the API exposing this service is functioning.  It is the problem in a service.  It is the service that has missed to ensure and mandate the presence of TdsServerTransID -- a business logic problem.

In simple, we Software Engineers [including me] use the term API vaguely and with no sense of what it means.  This is my observation.  Further, the Software Testers have tossed this term API in all possible ways and learning it in incorrect ways.  I have no doubt in it when I say this.

Next time, when you say it is a API problem, rethink on what you are saying.  Is it an API or the service(s) which is accessed through that API?  It is useful when we describing the behavior of the system and its layer.  

I cannot say it is a gear box problem for the gear stick not [usable] working, and vice versa.  You see that?

To stop here,

1. Testing skills and testing will help when it is collaborated with awareness and skills of the tech stack used in building the software system.
2. Testing skills, programming and tech skills are not enough!
• The domain skills and awareness is essential and critical.
• If one is aware of the domain where the problem is observed, then the 201 will not be read as HTTP status code.
3. Build the domain skills and maintaining the knowledge base as a GitHub project helps in a longer run.
4. Interfaces and its gateways should not be overloaded with additional responsibilities to make sure the mandatory key-value is present.
• If did so, one should learn why. Because, it is an anti-pattern and not a suggested software engineering practice.
5. It is the services that has problems most times.  
• The interfaces and its gateway will have the discovery, orchestration and traffic problems along with the risks of security.

References:

1. https://httpstatuses.io/
2. https://developer.elavon.com/products/3dsecure2/v1/api-reference
3. https://developer.ravelin.com/psp/api/endpoints/3d-secure/errors/
4. https://developer.elavon.com/products/3dsecure2/v1/3ds-error-codes
5. threeDSServerTransID  (in our case the JSON reads as TdsServerTransID)
• 3DS Server Transaction ID
• Universally unique transaction identifier assigned by the 3DS server to identify a single transaction.
• The 3DS server auto-populates and appends this filed value in the authentication request (AReq) it sends to bank in addition to the data you send.
• This value can also be found by a lookup in the response received by this service -- /3ds2/lookup

The { } and Lessons I Observed

 

I did not know { } are called braces.  I called them curly bracket or flower bracket in my verbal communication until I started my career.

In the early days of my engineering college, I wondered why the braces are used and not the square bracket or parenthesis to open and close the class, function and a block of code.  

I was practicing C, C++ and COBOL then.  Though COBOL did not use braces, it used indent to start from specific column in a row.   But, the philosophy of a programming language construct looked relevant in COBOL as in C and C++. 

When I practiced Core Java, I could relate the programming constructs and find the similarities in C, C++, COBOL and Java.  So with C#, JS, and Shell Scripting.

All this said, the question that remained in me is -- Why these programming languages use braces to open and close the class, function, loop & conditional blocks?  Why this similarity?

When I studied Discrete Mathematical Structures in a semester, I could correlate the programming to it.  This helped me to reason and interpret why the braces in a programming language.   

Pic: Programming languages having braces to open a function.

{ } and Set

In the Discrete Mathematical Structures, I studied Sets. Further, I learned how the Sets is used to classify and organize the elements in problem solving.

While I was solving a discrete math exercise,  this struck to me -- Why the braces to represent a SET?  This triggered my associative memory and sparked a question -- Why do I see the braces in C, C++, and C#?

Here is how I interpreted and reasoned my thoughts and questions.

• The SET is to represent the elements of common nature and characteristic which has a purpose. Most of the times it is deterministic.
• But, why the different programming languages use this braces to group a set of instructions? Why not something else to represent programming instructions with a common and deterministic purpose?  
• The COBOL do not use braces, but, the philosophy and thought process of braces exist in it as starting from specific column.
• I observed Java and Shell scripting using the braces.

The point and thought to note here is, the two words -- SETS and Groups. I'm studying this since my primary school days.  But, I had not realized how they are so much into the computer science!

Today, I observe most programming languages use the braces to group the set of instructions which are for a specific purpose.  Be it a class, function, loop or a conditional block, they are within { }.  

Between the { }

The instructions written between the braces has an objective.  Be it class, function, condition or loop block.  That is, I group this instruction as a set.

Why I call it as a set?

• The instructions between the braces have the one purpose.
• Is this SRP -- Single Responsibility Principle?  I am yet to put this in a better word!

Is the set a collection of elements that has a common characteristic and purpose?  Then, between the braces, the code has a common [one deterministic] purpose.  

Does this thought of programming language creators made to use the braces?  If so, this is a beautiful learning which is missed to observe and interpret.

{ } and Programming Languages

A programming language is created [written] to overcome the limitations of other language in a context.

Yet, each person who created the respective languages did agree to a common representation and understanding of semantics and constructs like the braces.  I see this is missing in Software Testing fraternity.  

Though, the creators of programming languages have a differing thoughts on other programming languages and what it takes, they have something in common to represent their thoughts.  

Looks like the most creators seem to go with this common representation.  The braces is one such example.  

Their vocabulary is something amazes me; most don't seem to have a problem with it.  The idea and thought are the same behind the vocabulary in most cases.

Another example is how to write a comment.  The programming and scripting languages that I have used so far uses // to comment a line.

To end this post here, personally I feel, I as a Software Test Engineer have a lot to learn from the programming fraternity.  

The next blog post is continuation of the thought shared here and sharing my experience of how the software testing fraternity looks to me in comparison to programming fraternity.

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

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.