Tuesday, August 24, 2010

QA or When do you flip a pancake?

When do you flip a pancake?  We know what a good pancake looks like.  It's nicely brown on both sides, with a cheery ring of white along the rim.  But when you start with a pitcher of pancake batter, and a restaurant full of hungry lumberjacks,  how do you get your pancakes to meet those requirements?

The requirements are completely unambiguous.  Brown sides.  White ring.  What could be simpler?  So let's design a development process that will make our pancakes come out right:
  1. Developer pours pancake batter.
  2. Developer flips pancakes at a rate based on the schedule.
  3. Developer throws "done" pancake over the wall to QA.
  4. QA inspects pancake.  Rejects are thrown back over the wall to the developer to "fix". 
Clearly, unless the developer is really good at estimating, the result of this process will be a lot of wasted pancakes, delayed breakfasts, angry customers, and accountants who, concerned about costs, suggest that pancake developers should be outsourced.

OK, so let's design a different process.  Based on our observations of pancake  cooking, we notice that the perfect time to flip the pancake is when the bubbles on the top have just popped, and the surface starts to look slightly dry.
  1. Developer pours pancake batter.
  2. Developer applies the test to determine when to flip the pancake.
  3. Developer sees pancakes are perfect and ships them.  
  4. QA simply observes the pancakes on a statistical basis.
When we apply this process, we find that QA hardly ever rejects a pancake.  Breakfast cooking becomes efficient.  Customers are happy.  Accountants, concerned about costs, suggest downsizing the QA group.

Moral of the story:  Developers are not done until the acceptance tests pass!

Who designs the acceptance tests?  QA of course.

I recently read a blog by Dennis Stevens entitled We Are Doing QA All Wrong. He is, of course, quite right.  We are, and have been, doing QA all wrong for years.  Indeed, the current role of QA only exists because developers have been so bad at doing their jobs.

QA is at the end of the process because development never learned when to flip the pancakes. Decades ago, frustrated by the terrible quality coming out of development, managers created an inspection step at the end of the process.  QA (or QC as Stevens would have it) was born.  This role for QA reinforced the bad behavior of development that spawned it.  Because QA was at the end, developers didn't need to care about getting things right.  Developers no longer had to worry about bugs; that was now QAs role.  All developers needed to do was to "say" that the code worked as far as they were concerned, and then throw it over the wall.  Deadlines are a lot easier to make when you don't have to make the code actually work.

Management, in order to justify the existence of QA to the accountants, who were very concerned about the cost, began to measure QAs efficiency.  The more bugs that QA found, the better the job they were doing.  Notice how insane that is!  The only way for QA to be measured well is for development to screw up royally.  The more bugs that developers create the better QA looks. 

And so an unholy alliance of blame avoidance was born.  Developers can appear to meet deadlines by delivering crap.  QA is measured highly because they find lots of bugs.  Everybody is happy -- except the end customer, and the accountants who are very concerned about costs.

Look, this isn't rocket science.  If QA's input is primarily at the back end of the process, you are going to have lots of waste, rework, delay, and angry customers.  I mean:  Duh!  (Pronounced "DUUU-uuuh")

So where do we put QA?  How do we break the unholy alliance, and stop avoiding the blame?  Simple!  Move QA to the front.

What if QA's job was not to test the product, but to design the tests that developers use to know when to flip the pancake?  If QA created suites of automated acceptance tests using tools like FitNesse, then developers would know when they were done.  Developers would continue working until the acceptance tests all passed.  Indeed, it would be the developers who executed those tests.  

This is how good agile teams are organized.  QA (and development) works with the business to define the requirements as a suite of automated tests that developers execute to know when they are done.  When all the tests pass, QA makes a final exploratory pass over the product, and sends it on to production.

That last step is a little more complicated than that, but is beyond the scope of this article.  Suffice it to say that exploratory testing is a craft in it's own right that needs to be part of the process on an on-going basis.

So, in the end, when do you flip a pancake?  What is the definition of "done"?  Developers are done when the automated acceptance tests design by QA all execute and all pass.

8 comments:

  1. I disagree with some of this because there is a major difference between pancakes and a full breakfast. If you test when the eggs are done, the bacon crisp, and the pancakes perfect and never test them together you get rubbery eggs from them sitting under the heat lamp, no one tested that the pancakes are located directly under the bacon and eggs and are inedible in this location.

    So, testing should also be done on the final product, and importantly user acceptance testing should also be done before breakfast is considered delivered.

    My point is, there are some GOOD things about QA being at the end. Most of it should be moved up front, but moving all of it is just as silly as doing it all at the end. After all, no good chef would send out a meal without proper plating and looking at how it appears visually to the diner.

    ReplyDelete
  2. A fairly good post. Have developers and QA become lazy because of corporate pushing in the wrong areas? I can see that being possible in some team environments.

    TestyReadhead adds some great insight here. Cooking is a passion of sorts that I'm always trying to learn and improve at home, so this makes me ponder, is the assumption here that the eggs and bacon are started at the same time as the pancake?

    In this analogy, the developer only has two hands and a pair of eyes, so naturally what get's started first? Is it the Developer who sides to work on X feature first, then Y? Is it the Manager, SCRUM Master, etc? This brings some interesting questions to light. The cooking analogy breaks down a bit because it is difficult for a Developer to work on multiple features at the same time, unlike on a cook top where you might have 4 or more burners, each with pans, pots, and skillets going away, allowing food to cook at the same time instead of in sequence, streaming off the grill one by one. So maybe you have a developer team working simultaneously on different features instead.


    However, this is worth considering further. I've run into this same problem in my kitchen with breakfasts actually. I've learned to mix up my batter, mix up my eggs (Since I prefer scrambled) first. Bacon is trickier to do since I often use a microwave so let me substitute sausage link or patties, for the sake of this hypothetical.

    Since I cook sausage on the stove top as well, I would always start the sausage first, and typically before I've done the egg mix. While the pancake griddle/skillet is heating up, then I throw in the first pancake, and I'll take a moment to get the egg pan ready too. Shuffling all three on the stove top though is a bit of an art form, and I gotta agree it is far too easy to overcook the pancakes, the sausage or the eggs, or worse under cook them.

    I've seen that this is a problem sometimes at restaurants. They are out of Fries so my burger often sits in a bag waiting on them to finish, and is cold by the time I get back home/work to consume it. Yuck! who wants cold food? So just like at a Steak House where I'll check to make sure the meat is done to my tastes, there actually is no way to really remove that last bit of testing by the customer, except that in the case of McDonalds, and other Drive Thru fare, how many people actually acceptance check their food before driving away? I know I try to do it with most of my orders, especially if I've special ordered something, but it is far too easy to drive off, with the order wrong I've found.

    In fact it may not even just be about testing the food. The number of straws, ketchup or other condiments missing, how about enough napkins for the entire family for the meal instead of like three for the five of us? Oh, and what if I need an extra straw for some reason or another. Sometimes the clerk at the window thinks about these things and asks. Do you need a carrier? (I've got five drinks, how do you expect me to hold them and drive, especially if my car only has 2 cup holders in the front, and there are only two persons in the car that you can see from the window? Talk about a pet peeve that is :)

    I can understand not asking if there were only say two drinks, but at 3 or more, sounds to me like these folks are probably not eating in the car, especially if I'm the only one in the car. However, not sure that fits in the analogy being hashed over here. Perhaps I've gone too far down the grease trap here.

    ReplyDelete
  3. This works very well if you're creating the same pancakes over and over again.

    The wonderful thing about testers is that they have some ideas about the ideal pancake *filling*. They got these ideas because they talk to people who love pancake filling. The real secret of their role is that they themselves *hate* pancake filling, and will happily point out your mistakes without eating all your maple syrup.

    ReplyDelete
  4. Wow, talk about people getting carried away with the food metaphor. Chefs don't delegate the quality of their food to a QA department, geddit?

    ReplyDelete
  5. Nice article! Can I translate this article and put Chinese version on my blog(http://neodream.info)?Thanks

    ReplyDelete
  6. I really dislike metaphors for software development, since there is always some piece which is totally different and kind of destroys the metaphor.

    ReplyDelete
  7. wonderful information, I had come to know about your blog from my friend nandu , hyderabad,i have read atleast 7 posts of yours by now, and let me tell you, your website gives the best and the most interesting information. This is just the kind of information that i had been looking for, i'm already your rss reader now and i would regularly watch out for the new posts, once again hats off to you! Thanks a ton once again, Regards, QA online trainingamong the QA in Hyderabad. Classroom Training in Hyderabad India

    ReplyDelete