Giving the Customer a Little Extra

It's 108 today in Oklahoma City, so I find myself blogging, working indoors, and playing some guitar.

I had a revelation awhile back at Five Guys Burgers. I know, for many people, revelations happen in church, during a sunset, etc. Mine happen while I'm stuffing my face.

If you have ever eaten at Five Guys, you know the throw an extra handful of fries in your bag on top of everything. There's a good chance you may get full on the fries before you ever reach the actual container of fries. This got me thinking about why they did this. Then it struck me, this is a Purple Cow. How many other fast food places do that?

In contrast, I got a burger and large fries from one of our local chains (Braum's) recently. When I looked at the fries, I could count them. There were 15 I think. Plus, they were those frozen ones, unlike Five Guys which are cut in the store (like In-n-Out).










It probably costs five cents or less to throw in the extra handful of fries. In return, Five Guys gets loyal and raving customers. I've never seen an ad - print, TV, web, anything, but I've talked to many people who brag on them.

So, what's the attraction? What makes the difference?

Isn't it nice when you get more than you expect, not less?

This is our new Five Guys in Moore. Someone apparently thought it was a drive-in.










It's sad that in our society, people are cynics about deals. I see this all the time in dealing with our customers at Rice Consulting. I quote a price and people ask, "What's the catch?". It's simple. There are no catches.

For example, I give 12 months for people to finish an e-learning course. Most of our competitors give 90 days. If someone needs more time, I always extend the time to take a course.

After a class, I'm always available to answer post-class questions for free. During an e-learning class, I always answer questions as part of the class fee. After a consulting engagement, I always answer post-engagement questions.

In the past weeks, here are some other great examples:

We bought a 2010 Ford Explorer recently from Reynolds Ford in Norman, OK. I didn't haggle on the price, bought the extra protection package, got Ford financing, the works. The whole process took a little over an hour and went as smooth as silk. Our salesmen, Brent was helpful, friendly and knowledgeable. Then, I discovered there was only one set of keys. So, I called Jayna at the dealership for an extra set since they cost about $200 these days for the chipped keys. When I picked up my car from the service area, they had an extra set of keys for me. Oh, and when we took possession of the car, it had a full tank of gas, was washed and the tires were glossed. That's extra for the customer and I'm a fan now. Reynolds Ford knows the value of a lifetime customer is more than $200.

Today, I bought two pounds of coffee at a Starbucks in Norman. The barista offered me a free cup of coffee. Even at 108 degrees out, I accepted. Let it never be said that I ever turned down a free cup of coffee. As James Garner (a Norman native) said in Support Your Local Sheriff, "I never turned down a cup of coffee in my life."

I have actually asked for a free cup of coffee when buying several bags of coffee at other Starbucks and the response was "Sorry, we don't do that anymore." That left me unimpressed. I'm much more inclined now to buy from the Norman store.

There used to be a time when giving a little extra to the customer was common practice. Now it seems that the trend is to reduce the product and charge the same. I believe that's a short-sighted approach.

It appears to me that giving added value is the result of both good policy (that's the role of management) and good performance (that's the role of the person delivering the service.)

At Five Guys, their corporate policy is to top off the fries. At Braum's, their policy is to not under any circumstances exceed the size of the container.

In other cases, like at Reynold's Ford and Starbucks, it's the performance of the right people making the right decision by the customer.

In software testing, we need to be showing our added value. One way to do that is to give a little extra to your customers. Be helpful to them. Ask what they need. If they don't know what they need, help them see the possibilities.

Some people see their customers as "those which must be endured." For sure, there are challenges. I choose to see my customers as the reason I'm in business - to serve and to stay in business.

You may not have a "business" but I suggest that you have many of the same reasons to please your customers. Without them, you wouldn't have a job.

OK, enough for now. I'll go practice Black Dog (Led Zeppelin) and Bach Cello Prelude 1. What can I say? I have a wide range of musical tastes!

Have a great weekend!

Book Review - Documenting Software Architecture, 2nd. ED

Authors: Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord, Stafford

Addison-Wesley, 537 pages

As a software tester, I rely heavily on system documentation. Unfortunately, documentation is often missing, obsolete, or never created in the first place.

Also, I have a great appreciation for software architects and the work they produce. As a former developer, I used to struggle with the best ways to express system architecture diagrams. After all, there are so many methods available to document systems – UML being a major one, but there are others.

When I started reading this book, I was struck by its practicality, beautiful simplicity, and integration between authors. Everything I read in this book is written in a clear and understandable way. The authors understand that different audiences will read this book, so they give graphical (of course) guidance in which chapters are most applicable to architects, stakeholders and novices.

This book covers the basics, such as module views and module styles, component and connector views, allocation views and styles.

Part two of the book goes beyond the basics and gets into issues regarding levels of detail, deciding among alternatives, documenting interfaces and documenting behavior. Part three is devoted to building the architecture documentation.

There are appendices devoted to UML, SysML and AADL to show how architectural documentation is shown in each of these.

It would be tempting to say that this book is needed for new technologies, such as SOA and the cloud, which is true, but too narrow. Actually, this book can be applied to any technology or approach – traditional, agile, iterative, or anything. That’s because the one thing people ask for and struggle with is documentation. This is especially true for architectural documentation.

Read this book and apply the things in it and you will stand out on projects - in a good way. And, of course, that’s a good thing!

Test Automation is Not Automatic

Recently while teaching a workshop on Testing Dirty Systems, I uttered this “Randyism” off the top of my head, “Test automation is not automatic.” I realized immediately that I had just concisely stated the problem in making test automation a reality in many organizations.

Most testers know that test automation is not automatic. (Wouldn’t it be great?) However, management many times does not know or accept that reality.

There are some test tools, such as unit test tools, that are practically automatically applied. My remarks in this article are aimed at the capture/playback and scripting tools for test automation.

The issues are that:

1) Not every test can or should be automated

2) For those tests that can be automated, it takes time and effort to build the automation

3) For those tests that have been automated, the tests must be maintained

4) It takes time to lean how to use a tool

5) It takes effort and planning to implement a test automation framework

None of these are automatic, even with the best of tools.

Not Every Test Can or Should be Automated

Think about the things you test that are not very repeatable. Or, they may be prone to constant change. Perhaps the things you test are developed in a technology that has little or no tool support.

Then, there are tests such as user acceptance tests that need people’s evaluation to judge acceptance.

Some tests require creativity and adaptation to perform. You may have to make judgments during the test, which may be too complex to describe in a script. Test automation leverages the mundane testing to give more time and attention to the unique tests.

Your job is to identify the tests that can be automated. (They don’t come labeled!) Then, you must understand the nature of the test, such as the pre-requisites, the steps to perform it, the exceptions and where to find the expected results. None of this is automatic. It’s all test design and test implementation.

For Those Tests That Can Be Automated, It Takes Time And Effort To Build The Automation

It’s one thing to automate a function, but another to design a good test of the function. That’s why capture/playback is so appealing, yet lacking. The issues are: What are you testing in the capture session? Then, how can you extend those tests to add value?

You have to apply approaches like data-driven testing and keyword-driven testing, which take time and effort to understand and implement. These are not “out of the box” deliverables.

For Those Tests That Have Been Automated, The Tests Must Be Maintained

This has been one of the consistent issues in test automation. There are things you can do to ease the maintenance burden, but it doesn’t do away with the issue.

For example, modular and reusable test scripts are very helpful in reducing the number of tests that must be maintained. Still, you must maintain the scripts you have.

This means you must know when the application has changed, what the changes were, and create new tests for those changes. This implies the presence of configuration management and traceability.

It Takes Time To Lean How To Use A Tool

Of course, the learning curve varies by tool, but the fact remains that a tool with sophisticated features will take some time to learn. The learning curve also varies by person. Some people with deep experience in automation may be able to learn very fast, but when you consider the wider deployment, most people will fall on the lower end of the experience scale.

The time also varies by the approach used to get training. Some people try self-learning which is noble, but typically takes longer than classroom training. Mentoring from an experienced person may be the best approach.

You must assess your organization’s skills and abilities to know even if mentoring will help. The best mentor in the world can’t help the person who isn’t ready to learn. Is that another “Randyism?”

It Takes Effort, Money And Planning To Implement A Test Automation Framework

The framework can take a variety of forms, but the context here is the organizational framework which provides a way to efficiently build and control test automation. Tools are only one-third of the picture. You also need processes with trained and motivated people to make everything work together.

Out of the box, tools are just software. A process framework helps with reuse and the maintenance of test automation.

Frameworks aren’t automatic, either. They must be adapted to fit each situation, therefore they require time, effort and funding to design and implement.

Conclusion

This article is certainly not an in-depth treatment of this topic. Entire books and training courses have been written to address these and other aspects of test automation.

I hope this expands on my simple statement “Test automation is not automatic” to provoke your own thinking on this reality.

For over twenty years now, I have seen a wide variety of test tool companies promote their tools as being effort-free, script-less, or however they choose to position their products. The evidence shows these are often empty claims. Just compare the numbers of people who have been successful in using test automation tools to those who have given up using the tools. It’s about 25% successful to 75% unsuccessful in my research.

I hope this article is an encouragement to those who have tried to implement test automation as well as to those who haven’t. It’s important to go into these projects with your eyes open and expectations at a realistic level. Once you get past the idea that the tools do all the work, you can do the planning and other work needed to increase your chances of success.

Test Manager Workshop with Randall Rice and William Perry

Name your software testing challenge and other test mangers and the workshop faculty will give you solutions!

As a software test manager, you face pressure from all directions. Customers expect high-quality products, project managers want to get the projects delivered on time, your management expects you to do more with less, and your team needs your leadership.

You could take a class in software test leadership or management, but much of the knowledge comes from the front of the room. What if you could determine the topics based on your own needs?

This is not a class or a conference, but a highly interactive and personal event. You will spend time personally with William Perry and Randall Rice to discuss your specific testing needs.

You need a mentor! Personal mentoring is one of the most effective ways to get guidance and build knowledge. Mentoring fills the gap that training cannot fill by giving you face-to-face, personal feedback about how to deal with tough issues.

In this unique opportunity, you can spend two days with two respected test management consultants, William E. Perry and Randall W. Rice to gain insight and solve your specific testing problems. Perry and Rice literally wrote the book on people issues in software testing. William E. Perry has written over 30 books on software testing and quality assurance. They share over 80 years of professional software quality and testing experience in world-class organizations.

Any and all topics are on the table. As an example, some of the topics suggested by test managers are:

• People issues in software development and testing
• Testing large and complex legacy systems
• Testing SOA and cloud-based applications
• Test metrics and measurements for showing your value
• How to grow as a test team leader
• How to communicate your value and your team’s value
• How to grow your team
• Test tools and test automation
• Software QA processes
• Software forensics
• Testing internal controls
• Testing information security
• Applying statistical methods to software quality
• Gathering and defining testable user requirements
• Managing expectations
• The Ins and Outs of software test certifications
• Any topic of interest to you!

However, the final topics will be determined by the attendees during the conference. That ensures your topic will be discussed!

You will leave this event with confidence and knowledge in how to best approach your situations.

Location – Orlando, FL (exact venue to be announced later)
Dates – Thursday, October 27 and Friday, October 28, 2011
Cost - $1,295 per person

Seats are limited, so reserve yours early to avoid disappointment.

Bonus Option!

Attend one day earlier to have an extra opportunity with Randy and Bill to learn how to test dirty systems.

The day prior to the workshop, William Perry and Randall Rice will be conducting a one-day interactive workshop based on their new book, Testing Dirty Systems. In this workshop you will learn:

• How to apply statistical process control (SPC) to software development and maintenance
• How to acquire system knowledge
• How to plan and perform the testing of large, complex and undocumented systems
• How to measure and report the test results in value-added ways
• How to use test results to clean a dirty system

Location – Orlando, FL (exact venue to be announced later)
Date: Wednesday, October 26, 2011
Cost - $550 per person if attended as part of the two-day Software Test Managers’ Workshop, $690 if attending only the one-day event.

Click here to register.

Click here to ask any questions.