I was in the middle of making a rather lengthy comment on Daniel’s most recent blog post when I decided it was long enough to warrant a full posting.

I wanted to get across the point that the situation Daniel finds himself in is not solely the plight of the software tester. Rather, anyone who esteems software quality runs the risk of being criticized, dismissed, or made fun of. Why is it that organizations and groups are so resistant to something that will improve their process, their product, and their bottom line. The idea is one I have been thinking a lot about, and I believe I have had an epiphany.

Sometimes, people are more afraid of success than failure!

Wait… what did you say?!? You heard right, and I’ll say it again. Sometimes, people are more afraid of success than failure.

I recently gave a presentation where I cited the Microsoft study on TDD that found:

The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

The idea that up to 90% of your test and fix cycles can be eliminated represents an enormous cost savings even if you factor in the high end estimate of 35% increase in initial development time. You will more than make that time up by not having to fix the 90% of bugs that are now gone from the system. With numbers like that you would think that management would be breaking people’s knuckles for not using TDD. Developer’s would be falling over themselves to TDD even the smallest spec of code just to avoid doing maintenance (curse the ground that software maintenance walks on).

But alas, there was no stampede. No rush to go forth and test. No proclamation from management that it must be so. So… what gives?

What gives is that it might just work! Developers might just write cleaner code, and be more productive. Testers might be able to confirm code quickly and have the freedom to explore automated acceptance testing. Deadlines might be met, and the company might save money. And… and… we might have to admit that we have been doing it all wrong for a very long time.

And there it is; the big white elephant in the room of software quality. Not fear of failure, but fear of success. Because success means having to admit things can and should be better. Even worse, that they could have been better all along. And we don’t like that. Most of us like to think we are pretty smart, that we are pretty damn good at what we do. When someone shows us a better way, our little bubble bursts, and we are forced to admit that we aren’t as special as we’d like to think we are.

The mediocre will always defend the status quo because their sense of worth is derived from being the smartest, funniest, sexiest, whateverist person around. They are a big fish in a little pond, and they like it that way.

The exceptional are never satisfied with the quality of their own work. They assume that there must be a better way, and seek out the best and brightest in the world to learn from. They draw their sense of worth from knowing they are better today than they were yesterday.

Exceptionalism is the arch-enemy of mediocrity, and success is it’s kryptonite!

If you are a little lost by the title, it will all make sense in a moment… um… sort of.

Until I started my career as a software developer I worked a lot of other jobs. I have had a job since I was 16 years old, and that was just an excuse to get out of doing manual work for my parents around the house. I’ve worked as a bagger at a grocery store, cashier at a big-box-mart, usher, concessions, and box clerk for a movie theater, tech support for a DSL provider, general laborer for a masonry outfit, and the last job I worked before slinging code full-time was waiting tables.

All of these jobs really have one thing in common: I was the person who always caught the tail end of the customer’s experience: whether it was good or bad… especially when it was bad!

Waiting tables is an interesting experience, and one I think everyone should have to do at least once in their life. As a waiter you are the face of the dining experience for the customer. Before the customer even gets there, you are preparing the store to make their time enjoyable. You clean the kitchen, wash dishes, stock pantry items, napkins, silverware. You go over your section to make sure that everything is set up correctly and clean.

Once a table in your section has been seated, as far as the customer is concerned, you are the restaurant. You size up the customer to figure out what kind of approach you should take (believe me it makes a difference). You give them an overview of the menu, get their drinks, throw out a couple of suggestions, and meticulously write down the order  making double sure to repeat back the order so there are no misunderstandings. Without delaying, you ensure that the order is put into the computer accurately and check to see that the kitchen staff gets the ticket. If needed you even explain any nuances of the order to the cooks: “‘SUB BAKER ADD CHEESE.’ Hey Joe, they want a baked potato instead of mashed, and they want to add cheese to the sandwich, NOT the baker!”

While waiting for the food you are feverishly busing, washing, and resetting tables for the next set of patrons that walk into your section; you make sure they think they are the first people to sit there. A single spec of food left on the table or the floor can ruin the whole meal! Every time you walk into the kitchen you are checking the status of your food.

“307 IN THE WINDOW!”

Your order is up and now you are checking every detail to make sure the food you have matches the ticket. You tidy up the presentation a little and make sure the plates are picture perfect. Drop the food off to the table and make sure they have everything they need: drink, condiments, extra napkins, steak knives, etc… You let the table dig in and about two minutes later you come back to make sure everything was up to par. You never take them at their word either! You have to actually look at their plates, and their faces to see if they are telling the truth. Most people are too sheepish to tell you everything sucks, and they will simply not come back to the restaurant if the experience is bad. It is up to you to see this and recover their patronage.

Ok. So what? Why waste your time with this?

Because QA and waiting tables have a lot in common. As QA, you are the standard bearer for a quality user experience much the same way that a waiter is the standard bearer for a quality dining experience. In order to really be effective you have to be involved in the process from start to finish. You need to be there when the user story is first conceptualized in order to effectively develop a testing strategy. You need to determine the set of criteria by which a story can be considered done (acceptance criteria). You also need a repeatable way to ensure the story as coded meets those criteria (Fit/FitNesse, StoryTeller, Selenium).

As the story is being developed you need to be in constant communication with the developer (cook) to make sure that any misunderstandings are cleared up immediately. Developers make assumptions if the acceptance criteria are vague. So find out what those assumptions are, and refine your acceptance tests accordingly. Be proactive about communicating your testing strategy to the developer(s) working on the story so they won’t be tempted to just throw it over the wall. A good developer will make your job easier here, but good acceptance tests do NOT care how well written the code is. Remember that your main goal is not to find bugs, but to verify that the feature/product will meet the customers needs. An acceptance test that fails is not a bug, it is simply an incomplete feature, and we don’t ship incomplete features.

Being a QA professional takes a lot of discipline and involves a lot of responsibility, but it is your job as a professional to demand software quality above all else. A professional will stand on principle in this area while an amateur will make excuses for the level of quality… “I don’t have enough time to do automated testing! The developers write bad code! My boss doesn’t appreciate QA!”… All those things may be true, and may make it harder to do your job, but it doesn’t change your job!

QA can be a tiring and thankless job, but the professional derives pleasure from a job well done. Be committed to the project/story/user, and not your own hide. This is what separates “testers” from Software Quality Professionals. This is the difference between a great user experience and a mediocre one.

The meal is over, and the customer is satisfied. On their way out the table says “The meal was excellent! Be sure and thank the cook for me,” as they hand you a three dollar tip.

“I’ll do that sir!” You say with a smile, knowing that you did your job. You made sure that everything was perfect. You took care of all the grimy little details so they could concentrate on what they came there for… a good meal.