Track who is running—and not running—automated checks

When: Developers are reluctant to participate

In cases where developers came from a more structured process background—where programmers write code and testers test it—teams had problems getting programmers to participate in the process. This has to change for Speciication by Example to work.

Pierre Veragen had a unique solution to get programmers involved in the process. He created a simple centralized reporting system that told him when and where the executable speciications were checked:

In the ixture code I put a little thing that told me when people were running tests on their machines. That group was pretty shy. I used this to ind out when people aren’t running the tests to go and talk to them and see what’s wrong and whether they had any problems. The idea was to get a more objective feedback than “Yes, it worked fine.”

By tracking who isn’t running tests before committing, he was able to focus his efforts on the team members who had issues or required assistance. Veragen says that all the programmers knew about the process from the start, so that instead of monitoring the actual test results, he tracked only whether someone executed tests.

Monitor when tests are being run, so programmers will run automated checks.

This is an interesting approach for larger teams, where a coach cannot work with all the members all the time. I expect the effects to be similar to publishing the locations of speed cameras on highways—programmers will know that someone is looking, and they’ll take more care to run the checks.

How teams integrated collaboration into lows and iterations

Understanding how to it collaboration into a delivery cycle is one of the biggest challenges when teams start implementing Speciication by Example.

50 Speciication by Example

Diferences between Speciication by Example and Waterfall analysis

† http://skillsmatter.com/podcast/agile-testing/how-to-sell-bdd-to-the-business

There’s no universal solution for a process change, and each team will need to decide how best to extend their way of delivering software. Following are some nice representative examples that will help you get started. I’ve chosen three good case studies, one for each popular process. The Global Talent Management team works according to a low-based Kanban framework. The Sierra team delivers software using an Extreme Programming iteration-based process. The Sky Network Services group runs iterations based on Scrum.

Global Talent Management team at Ultimate Software

The Global Talent Management team at Ultimate Software is one of 16 teams working on their human resources management system. The team consists of a product owner, a user experience expert, four testers, and ten developers. When I interviewed Scott Berger and Maykel Suarez, who were part of this team, their project had been under way for eight months. The team uses a Kanban low process.

Because the product analyst (a combination of an analyst and a product owner) is busy, the team tries to use his time eficiently when collaborating on speciications. The product analyst explains a story at a high level with “story points” (in their case, story points aren’t estimates of complexity but bullet-list items that explain stories). They avoid technology-speciic language as much as possible when writing story points. The story is then added to the Kanban board as part of the backlog.

In a daily meeting, limited to 30 minutes, the lead engineers meet with the product analyst and anyone else on the team who is interested in the backlog. They quickly run through the stories in the backlog, checking that each story is sliced correctly, that it makes sense, and that it’s implementable in four days or less—as a team, they imposed this deadline for each story. During the meeting, they also clarify any open questions and look at story dependencies.

The story then goes into a queue for writing speciications with examples, which are used as acceptance tests. A team member who will work on implementing the story pairs up with someone who will focus on the testing to write the outlines of these speciications. (They don’t have formal tester or developer roles in the team, but I’ll use those roles to refer to this pair of people in this section to make it clearer.) Berger explained:

By leveraging this pair, we’re able to cut down on the necessary tests required for this story, because a developer has more intimate knowledge of the code. This has proven quite successful, because these pairs generally root out any inconsistencies and design laws that exist and aren’t caught in the initial story review.

After they deine an outline, the tester usually completes the scenarios in a Given-When- Then format. The pair and the product analyst meet and review the scenarios in an in-depth Story Knowledge and Information Transfer (SKIT) session. This addresses the risk that a programmer and a tester won’t be able to come up with good speciications without an analyst. When the product analyst approves the scenarios, the team regards them as the requirements. Other than minor text alterations, no further changes are allowed to these requirements until the story is delivered.