A Lesson Learned in Really Bad Customer Service from Bob Howard Toyota

It's been an interesting weekend. I like to try to see the lessons even in bad situations in life. I also like to use real-life business situations to learn and apply lessons about customer service. For example, if you want to experience really great customer service, just visit any In-n-Out Burger. I'm always amazed.

On the other end of the spectrum, just visit most MacDonalds. They seem to have mastered the ability to forget that the customer is the one that keeps them employed. I experienced that this weekend, but here's the one that really got me.

I spent Saturday morning with my adult son trying to get some help on a car deal gone bad. It's a long story, but the short version is that we went to a supposedly reputable dealer here in the Oklahoma City area (Bob Howard Toyota) looking for a used 4Runner. We were shown and sold a Land Runner which belonged (but not exactly - we found out later he had just registered the vehicle but didn't have the title yet) to one of the salesmen. Therefore, it was a private sale which took place on the lot. About a week later, the vehicle started overheating and eventually (after $600 of repairs) learned that it is a blown head gasket. (About another $1,300 in repairs)They told us if we had any problems, just to come back in and they would help us get anything fixed. OK. That didn't happen.

You can read the longer version here: http://ryanrice.blogspot.com/.

So, we went back in yesterday and asked to speak with the general manager. I was expecting at least a somewhat friendly attitude. Instead, we got a jerk who acted like we were wasting his time. He took no ownership of any issue. When I asked him how he felt about salesment flipping cars on his business lot (essentially taking away his business), he agreed he didn't like that.

OK, so here's the point of this story. 1) I want the local community to know through Google, and 2) it amazes me that the manager could not even treat like a potential customer, which we were.

I would point you to a great book called "Customers for Life" by Carl Sewell, who owns one of the premier car dealerships in the U.S. From Sewell's experience, a satisfied customer who returns to your business for life will spend hundreds of thousands of dollars. Plus, they will tell their friends. I know many people who have used the lessons in that book to transform their businesses into customer-friendly businesses.

I wonder how much money Bob Howard Toyota spends on television ads. (In Oklahoma City, it seems that all you see are car and furniture ads!) I'll tell everyone I know about how badly my son and I were treated there. I've later learned, there have been others. This story makes ours look tame: http://www.ripoffreport.com/reports/0/155/RipOff0155248.htm

This experience has burned in my memory the value in treating my customers right. My current and past clients will tell you that I will bend over backwards to serve you well. That's why I offer a no-risk, no-hassle guarantee on all my e-learning offerings. If you aren't happy, neither am I.

It's not just about the money, either. It's about doing the right thing, about being treated like I would like to be treated. I learned my lessons in customer service from my father who owned and ran a service station when I was a child. I saw first hand how well he treated people and how they kept coming to his station for gas. Those were the full service days - I washed my share of windwhields!

As testers and QA professionals, we all have customers. Yes, internal developers and users are our customers. One of the best ways a QA or test team can earn respect and show value in a company is to treat our customers well. Like at any business, it is the customer that keeps you in business. That is true for both you and me!

Thanks for listening. It was cheaper than therapy!

Have a great week!

Integration and Interoperability Testing of Software

My last post about the American Airlines baggage system failure mentioned interoperability testing and it got me thinking about this important type of testing that is often minimized or overlooked in systems testing.

First, I just need to make a distinction realizing that software testing terminology is often applied in a variety of ways depending on how you were exposed to it. For example, a test case can mean many things to different people. Although standard definitions exist, they are often unknown to professional testers.

So, here are my working definitions:

Integration testing is the verification or validation that data and control can be passed correctly between two or more related systems or system components. In other words, "Can each component or system talk to each other correctly?"

Interoperability testing is the verification or validation that data and control, once passed correctly between two or more related systems or system components, can be applied correctly to achieve the expected results or behavior. In other words, "Can the passed data or control be used correctly to get the right outcome."

The idea is that it's one thing to have integration between items, but another for that integration to be applied correctly. By the way, the definitions I used are the same or similar to that used in defense applications where integration and interoperability testing is paramount.

I consider integration testing a phase or level of testing performed once the related items or systems are available. I consider interoperability testing a type of testing, which can be performed at any phase of testing, from unit to user acceptance testing.

Here's a fictitious (but realistic) example of the two tests in action based on some of my previous rants (er.., comments). Let's say that I am passing some data to another system for sending a passenger's bag to the right destination - either the conveyor belt to be picked up, or on to their next flight. The integration test would tell me if the data made it correctly to the sorting system. The interoperability test would tell me if the sorting system processed that data correctly, made the right determination, and then sent the bags to the correct destination. It is possible that a logic error could send bags that were meant to be on a connecting flight to the conveyor belt for pickup. (NOTE: I must emphasize this is just an example and not what happened with the American problems. It may have been something similar, but the information is not available yet to know what happened.)

The lesson we can all learn is that this type of end-to-end interoperability testing is hugely important but not necessarily easy. Many times it requires validation in the actual operational environment to get a true assessment of correctness.

By the way, I offer a course in Integration and Interoperability Testing.

One more realted note - I found this link to one of my favorite articles from Scientific American on software defects. It's called "Software's Chronic Crisis". Although it's from 1994, don't let the date keep you from reading this very informative article. I'm really glad I found it!

Do you have any experiences with performing (or not performing) interoperability testing? If so, I would love to read your comments.

American Airlines Baggage Failure Gets Personal to Me

I have posted previously about my disdain for the term "glitch", especially when it is misused to describe a major computing problem or failure. "Glitch" just sounds too casual and minor. Such was the case last week when a software defect caused the separation of thousands of bags from their owners and the delay of flights at New York's JFK airport on Wednesday and Thursday.

My wife and I got caught up in the mess. It all began when we missed our connection in Miami. It was close, but the plane left EARLY. Our only recourse was to change routing through JFK. I asked the lady at American, "But isn't that where they're having all the problems with baggage?" She assured me everything was in order. But...we had to spend the night by JFK without our bags, hoping they followed us to our final destination. Guess what? They didn't.

So, we had to buy all the things we needed, plus clothes to wear at the event we were attending, which had a dress code. The "I heart NY" t-shirts just wouldn't cut it. So, the glitch cost an extra $500. I wonder how many other people had similar experiences.

Some people think delays aren't a big deal. Well, with tight connections, cancelled flights and full flights, they can make life miserable is a hurry. Some of my friends had their flight cancelled in this debacle and missed the first day of a vacation they had really looked forward to.

I know, I know....I normally carry on everything. This time I was with my wife who must check a bag, so I thought, "what the heck?" I broke my own rules!

So now I've had a little taste of what the people at London Heathrow's new terminal 5 experienced.

When we think about the cost of computing defects, these are the costs we often forget - loss of time, loss of opportunity, loss of credibility (I trust an airline to get my bags from point A to point C only at my risk. Actually, anymore when I arrive on time at my destination, I'm ahead of the game. I'm so used to being delayed, I've come to expect it.).

OK, now I'm just whining.

In this case, the suspected problem was the interface with the baggage sorter's communication network, which is only less than one year old. Those darn interoperability problems! I wonder...if the system was ever tested end-to-end in the actual operational environment (also known as validation). If anyone knows the answer to that, please let me know.

I am on my way home and I sure hope our bags make it with us. Oh, and yes, we are flying through JFK again!