Test and Measure DON’T JUST BREAK How storytest- SOFTWARE.driven development is MAKE changing the SOFTWARE.way QA, customers, STORYTEST-DRIVEN DEVELOPMENT (STDD) IS AN EXTREME PROGRAMMING PRACTICE. and The basic premise is that before developers any code is written, a team takes work. a story (or rough idea of a require- by Tracy Reppert ment) and fleshes out that story by producing an executable “story- test.” Opponents say that STDD is “cowboy coding,” or “snake oil,” or 18 BETTER SOFTWARE JULY/AUGUST 2004 www.stickyminds.com MACK/REDUXPRESTON PLUS STDD rates high with the development team at Nielsen Media Research. Standing (l to r): Thomas Hund, Praseed Thapparambil, and Pam Smoot. Seated (l to r): Cheryl Redding, Rhoda Foxworthy, and Merrilee Albright Test and Measure specific contract for acceptance, so dis- crepancies are quickly resolved. There’s a “Creating the expected results clear context for customers and develop- was quite challenging, but it ers to have a conversation and weed out was rewarding when they ran.” misunderstandings. The risk of building —MERRILEE ALBRIGHT the wrong system is much lower.” Ken Auer, president of RoleModel Software and one of the earliest practi- just “a hindrance to real work.” Propo- expectation of the customer into an exe- tioners of STDD, agrees. His team, along nents argue that STDD produces the sim- cutable and readable contract that pro- with Ward Cunningham, first used plest system possible and is the wave of grammers have to obey if they want to STDD to produce a software system in the future, the new frontier. claim a working system. 1999. “STDD made it easier to nail “STDD gets the right people collabo- down what our end-users wanted,” re- EVERYONE GETS A SAY rating at the right time,” says Joshua calls Auer. “By having executable re- With traditional acceptance testing, de- Kerievsky, XP coach and founder of In- quirements for each story, we were able velopers would create an entire system, dustrial Logic, Inc. STDD brings together to know when we had completed stories, declare it finished, and then submit it for the customer, developers, and testers be- which made project tracking a whole lot acceptance testing. This mostly manual fore any code has been written. They col- easier and better.” testing tended to get bogged down in pa- laborate to identify a specific piece of perwork and occurred so late in the de- functionality, or “story,” to be worked NO ONE HAS TO BE velopment lifecycle that any mistakes on. Customers and testers then specify THE BAD GUY were very expensive to fix. Even if the criteria to validate that the story works Raha explains that not only does STDD system met all of the stated requirements and create an executable document that relieve stress; all the involved parties love and passed through acceptance testing can be accessed by anyone on the team. the process. “Customers love it because with flying colors, the customer, who “When testing is done after the fact, of the new level of confidence they get— hadn’t seen the system since the require- customers simply say that the system is instead of just hoping the development ments meeting, often was left feeling like broken when it doesn’t meet their require- team has understood the requirements he had not gotten what he wanted. ments,” says Somik Raha, XP coach for correctly. Developers love it because STDD makes it possible to formalize the Industrial Logic. “With STDD, there is a there’s no way they can be accused of from being lost in abstract discussions and vague generalities. A GLIMPSE To illustrate, let’s suppose a business has a rule that, for ac- counting purposes, all months are treated as having thirty days. OF STDD (Some bonds are valued under a similar rule.) One of the stories might be “Implement the 30-day rule.” The business expert IN ACTION. might write something like this on the whiteboard: by 1 April to 1 May is 30 (as normal) Brian 1 Feb to 1 March is 30 (even though 28) Marick 1 Jan to 1 Feb is 30 (really 31) QUESTIONS should follow. A programmer or tester might ask if STORYTESTS AS PROPS FOR CONVERSATION it’s really true that the number of days from 1 January to both In order to estimate a story, programmers have to understand 1 February and 31 January is thirty. The business expert would what the business expert wants. They learn this through face- answer that it is. Then someone else might ask, “So, it’s twen- to-face conversation. The business expert describes the feature, ty-seven days from 1 February to 11:59 PM on 28 February, but explains why it’s useful, and gives examples, perhaps scribbling the next minute it’s thirty days?” The business expert might them on a whiteboard. The programmers ask questions, split start to answer “Yes,” only to be interrupted by someone say- the feature into constituent parts (smaller tasks), ask more ing, “Not if it’s a leap year,” which would lead to a discussion questions about those tasks, and sometimes propose variations of the relevance of leap years, and then, perhaps, to whether on the feature that might be simpler to implement. time zones matter. That discussion might well be cut short, because the point EXAMPLES are particularly useful because they ground the con- here is for the programmers to have enough information to es- versation in something concrete and keep important details timate accurately, not for them to know every last detail. 20 BETTER SOFTWARE JULY/AUGUST 2004 www.stickyminds.com Test and Measure building a system that is not acceptable. THE FIRST STEP CAN helps teams obtain the necessary amount And QA loves it because programmers BE A BIG ONE of story details when they need it—before aren’t viewing them as the bad guys,” If STDD is so great, why do so many peo- writing code. says Raha. ple distrust it? Perhaps some of the skep- Even now that most of the quirks STDD challenges the notion that QA tics of STDD haven’t experienced it since have been worked out, people may still has to play a rival role to a programming its inception. XP and STDD definitely had be wary of such a big change. “It was dif- team if they expect to be able to spot de- some growing pains. Joshua Kerievsky ex- ficult to trust the process in the begin- fects. In practice, teams find that they plains, “In the early days of XP, we did a ning,” says Pam Smoot, senior project are saving a lot of time by having QA lot of unit test-driven development and manager at Nielsen Media Research, help produce storytests from the begin- would automate storytests only after we’d which began implementing STDD for a ning. “A tester is sometimes viewed as written our code. The trouble with this major data-warehousing project, “but it’s an adversary, when all they are trying to approach was that it was often hard to get so much better than what we used to do. do is ensure that the delivered product subject matter experts to define storytests, Having expected results created upfront functions well,” says Merrilee Albright, lead SQA analyst at Nielsen Media Re- search and member of an STDD team. “It was difficult to trust “I’ve been testing a long time, and have the process in the beginning, found that my role on this team definite- but it’s so much better than ly has more respect than it might in the normal software development process. I what we used to do.” —PAM SMOOT can utilize the expertise of other team members to help me create tests. Having the customer available to review the test which meant that with successive itera- by a business/QA person helped us find results and make suggestions immediate- tions we would get further and further be- miscalculations, misinterpretations, and ly has proved invaluable. Creating the hind on the number of storytests we still miscommunications right away rather expected results was quite challenging, needed. That produced higher defects, than late in the project.” but it was rewarding when they ran and since the lack of sufficient story details led Skeptics begin to see the value of ensured that the system was functioning to code that failed to fully satisfy customer STDD in just a couple of weeks, accord- as expected.” expectations.” He adds that STDD now ing to Smoot, though it can take a few CONVERSATIONAL EXAMPLES getting those tests to pass, other people can contin- BECOME STORYTESTS ue writing tests. The test-driven style is to make tests Once the iteration is planned, it’s the job of the programmers pass one at a time; while working on one test, the continued to produce features that satisfy the business expert, and it’s programmer doesn’t worry overmuch about what > the job of the business expert to support them—mainly by be- tests remain. So it doesn’t matter if some of those ing available for further conversation. For example, a program- tests are not yet known. These storytests do not necessarily mer might realize that she doesn’t know what the program completely replace conventional testing. They’re designed to should do in some special case, so the business expert has to build quality into the product. Someone else still needs to cre- tell her. Or a programmer might realize that the code is so ate tests to detect where the storytests fell short of the goal structured that it would be trivial to add a new wrinkle to the of preventing bugs.