StoryTest-Driven Development (STDD) Is an extreme programming practice. The basic premise is that before any code is written, a team takes a story (or rough idea of a requirement) and fleshes out that story by producing an executable "storytest." Opponents say that STDD is "cowboy coding," or "snake oil," or just "a hindrance to real work." Proponents argue that STDD produces the simplest system possible and is the wave of the future, the new frontier.
Everyone Gets A Say
With traditional acceptance testing, developers would create an entire system, declare it finished, and then submit it for acceptance testing. This mostly manual testing tended to get bogged down in paperwork and occurred so late in the development lifecycle that any mistakes were very expensive to fix. Even if the system met all of the stated requirements and passed through acceptance testing with flying colors, the customer, who hadn't seen the system since the requirements meeting, often was left feeling like he had not gotten what he wanted. STDD makes it possible to formalize the expectation of the customer into an executable and readable contract that programmers have to obey if they want to claim a working system.
"STDD gets the right people collaborating at the right time," says Joshua Kerievsky, XP coach and founder of Industrial Logic, Inc. STDD brings together the customer, developers, and testers before any code has been written. They collaborate to identify a specific piece of functionality, or "story," to be worked on. Customers and testers then specify criteria to validate that the story works and create an executable document that can be accessed by anyone on the team.
"When testing is done after the fact, customers simply say that the system is broken when it doesn't meet their requirements," says Somik Raha, XP coach for Industrial Logic. "With STDD, there is a specific contract for acceptance, so discrepancies are quickly resolved. There's a clear context for customers and developers to have a conversation and weed out misunderstandings. The risk of building the wrong system is much lower."
Ken Auer, president of RoleModel Software and one of the earliest practitioners of STDD, agrees. His team, along with Ward Cunningham, first used STDD to produce a software system in 1999. "STDD made it easier to nail down what our end-users wanted," recalls Auer. "By having executable requirements for each story, we were able to know when we had completed stories, which made project tracking a whole lot easier and better."
No One Has To Be The Bad Guy
Raha explains that not only does STDD relieve stress; all the involved parties love the process. "Customers love it because of the new level of confidence they get—instead of just hoping the development team has understood the requirements correctly. Developers love it because there's no way they can be accused of building a system that is not acceptable. And QA loves it because programmers aren't viewing them as the bad guys," says Raha.
The First Step Can Be A Big One
If STDD is so great, why do so many people distrust it? Perhaps some of the skeptics of STDD haven't experienced it since its inception. XP and STDD definitely had some growing pains. Joshua Kerievsky explains, "In the early days of XP, we did a lot of unit test-driven development and would automate storytests only after we'd written our code. The trouble with this approach was that it was often hard to get subject matter experts to define storytests, which meant that with successive iterations we would get further and further behind on the number of storytests we still needed. That produced higher defects, since the lack of sufficient story details led to code that failed to fully satisfy customer expectations." He adds that STDD now helps teams obtain the necessary amount of story details when they need it—before writing code.
Even now that most of the quirks have been worked out, people may still be wary of such a big change. "It was difficult to trust the process in the beginning," says Pam Smoot, senior project manager at Nielsen Media Research, which began implementing STDD for a major data-warehousing project, "but it's so much better than what we used to do. Having expected results created upfront by a business/QA person helped us find miscalculations, misinterpretations, and miscommunications right away rather than late in the project."
Skeptics begin to see the value of STDD in just a couple of weeks, according to Smoot, though it can take a few months to fully absorb it, explains her fellow team member, product manager Rhoda Foxworthy. "Now everyone on the team really sees its value and is excited about taking it outside the team, although we're not sure how," says Foxworthy. "Our next big challenge, when our platform team is retired, is continuing its spirit and use in a production environment where there are walls and naysayers."
Change Is Hard—But Worthwhile
Many STDD practitioners encounter an ironic reaction to their success: resentment from the rest of the organization. "It's weird that that happens, but it does," says Ward Cunningham, whose FIT tool is typically used for STDD because team members with diverse backgrounds can understand it. Cunningham continues, "It's just one of those quirks of human organization. Attitude is based on experience, and eventually people shift their attitudes and realize this method is to their advantage."
Considering such human quirks is key to successfully integrating STDD. "People always resist paradigm shifts," says Raha. "So it's especially important to introduce STDD when a project has just begun and people are still motivated."
As with any XP practice, keeping the STDD process going can be challenging if it's considered to be merely an option and not a rule. "STDD should be followed as a policy from the top down," says Narkeeran Narasimhan, a testing specialist for Ansys Corp., which develops engineering simulation software and has been doing XP since 2002. "Over a period of time, these processes can get compromised if, for example, new developers don't want to learn a method, and their managers—not wanting to upset them—don't want to enforce it."
The key to making the change is just getting people to try things, explains Cunningham. Developers who do try STDD tend to love the influence it has on a software design. "When I started doing STDD, I was amazed at how much simpler my code became, versus the code I'd written using either upfront design or minimal design with unit test-driven development," says Kerievsky. "Following STDD closely enabled me to produce designs I simply would not have anticipated."
“There’s really no situation in which I can see STDD not being the best process to use,” says Thomas Hund, senior SQA analyst at Nielsen Media Research. "As well as it's worked for us, I’m a believer."