Agile Testing with Lisa Crispin

In the late 90s I worked as a tester (I cringe now remembering my title, “Quality Boss”) at Trip.com. We were a waterfall shop (hadn’t heard of XP, Scrum or the like yet) with some talented programmers and testers. Until it was sold, it was a wonderful place to work. The CEO really cared about the employees, as well as the customers.

Working on one big project, someone started a whiteboard with funny things developers said during the coding and testing phases. The programmers took some of the choice quotes and embedded them in an Easter egg in the application. I printed them off for posterity, which is good, because that particular application was short-lived (though Trip.com lives on as Cheaptickets.com, and the url for the app still redirects there).

I am sure these are quotes you’ve all heard before! The Easter egg was invoked by some combination of inputs and keystrokes in the UI, and resulted in a page that said:

“An error has occurred — when asked about the problem, our developers would probably respond with:”

One of the following responses would come up, randomly:

• “I could just do it so it works”
• “Have you been able to get anything to compile?”
• “If you don’t think that it’s your fault, blame the tools”
• “Hmmm…. That’s bad”
• “It’s working for me”
• “We found out why the query page isn’t working… there’s something weird going on”
• “Who needs error checking?!”
• “Just add more memory”
• “Never show your code your fear.”
• “Sweeeeeet!”
• “Oh, it doesn’t compile? Just comment that part out.”
• “In order to fix the bug, you must become the bug.”

Reading these gave me a laugh and brought back many good memories. But there was bitter with the sweet. Though we successfully delivered the functionality of this project, the product people had failed to communicate (and we had failed to elicit) their number one priority – the search results had to come up within some short amount of time, and they didn’t. The project was a failure.

About a year later, the company was sold, one of the programmers discovered XP Explained by Kent Beck, and we all left to form a new startup and try XP. The rest is history! :->

This month’s issue Dressage Today had some articles about the two-time Olympian dressage rider and trainer, Steffen Peters. He talked about the role of discipline in turning dreams into reality. For him, this means keeping himself mentally and physically fit through a thoughtfully planned exercise and diet routine, as well as understanding the capabilities of each horse and how it can learn best.

My own dressage trainer tells me all the time, “It takes a million repetitions to change a bad habit.” That’s only a slight exaggeration in my case. I remind myself (and she reminds me) about 50 times a ride to correct each bad habit, for example, to put my hands closer together and keep them centered over the horse’s withers. Some of my bad habits are 50 years old, so they’re hard to fix, but I’m slowly getting better.

Discipline is a critical component of delivering high-quality software, too. We need to thoughtfully plan to use the right practices for us. We need to remind ourselves every day, via big visible charts, information radiators, retrospectives, any means that works to learn new good habits and reinforce the things we do well.

During a recent estimating meeting, our product owner (who normally knows better) asked, “About 6 weeks ago you estimated this XYZ story at 5 points. Is there any cheap, hacky way to do it for one point?” One of the developers responded, “Possibly, but we are not going to do a cheap, hacky solution”. It’s tempting to cut corners to meet a business need, but hacking in a quick fix that increases our technical debt down the road isn’t the way to do it.

Another example where discipline and good habits came into play occurred in this morning’s Scrum. A couple of the customers brought up a significant piece functionality that they had accidentally omitted from a story we’re already working on. It was tempting to say “OK, we’ll add that in too.” But it was too big a change to put into the story at this late date. We discussed possible workarounds, and one of the customers came up with one that would do the job. They will write a new story, and if we can, we’ll pull it in this sprint. If not, they’ll get it two weeks later.

Sometimes we do make compromises about quality, and implement a solution that is less than ideal. There are always business trade-offs to consider. But we don’t make these lightly. And even after more than five years of agile development, we spend time on a serious retrospective every iteration, and work hard to keep improving the way we work and the quality of our code. Some of our bad habits have been hard to fix, but we keep working at it. Our business continues to grow, which to me is the best feedback about our disciplined approach to keeping up good habits and eliminating bad habits.