program selection system

It’s easy to speak of test-driven development as if it were a single method, but there are several ways to approach it. In our experience, different approaches lead to quite different solutions.

In this workshop, we’re not trying to decide which approach is best. Rather, we’ll use concrete examples to explore

• What goes into the moment of decision when a test is written?
• How do you think about the problem you’re trying to solve?
• What strategies or techniques help you write the first few tests?

First 90 Words:

Software testing requires a diverse set of skills, demonstrated in complex testing environments. The study of traditional magic principles can help software testers raise their awareness of discrepancies that can be found in these environments, leading to improved quality assurance. Software likened to a magical “trick” offers an interdisciplinary approach to the study of method and effect, enabling us as professionals to approach testing from new angles. Magic in this context will not only educate but will also entertain!

One of the premises of the Examples Stage, and indeed, of all of Agile, is that good code is the result not of any up-front design process, but is instead the fruit on an inductive, iterative, incremental stepwise process that exploits experience and hindsight. Software fitted to its requirements is one result of such a process. Mature abstractions, and yes, even patterns, are another. Patterns, are after all, distillations of commonalities drawn from the designs of real code.

Improv theatre is acting without preparation and without a net; given a situation, improv challenges you to participate in a new reality on the spot. As such, it’s a powerful means of learning, and exploring, stimulating creativity, engaging in rapid decision-making, and building empathy-all skills that come into play in agile development projects. In this session, we’ll scratch the surface of improvisational theatre through a series of simple exercises and games. Session attendees are strongly encouraged to participate or simply to observe as their comfort level permits

Executable requirements looks like a great technique, just as using tests as specification sounds like a great idea. These techniques and concepts are radically changing the way software can be specified and produced in agile teams. On the other hand, FIT has been out for a while and no big revolution in software development happened (yet?). Was FIT only “another nice tool” to support agile development ? Are we expecting better tools to start the revolution ? Or did we just miss the point of using tests for defining requirements ?

See ET in action, using interesting interactive shockwave applications found on the Net. With audience particpiation, we’ll explore for both quality and bugs. We’ll introduce software attacks, quicktests, session based testing and other techniques. See bug types that ET is best at finding, even with great TDD. Developers will see how to think like a tester, ready to write better tests, or prepped for explorations on your own projects. Testers will hear some of the latest ideas, and probably pick up testing tricks as well. We’ll also have fun!

Original summary:

Drawing on the combined wisdom and energy of Project Runway, Scrum/XP and Artful Making this session will see small teams create an outfit, or outfits using a combination of conference clothing (especially Agile 2008 shirts) and a rag bag of fabric and accessories provided by the facilitator. This will be a 3-hour Scrum/XP immersion. Teams will work with their customers to establish a vision for the outfit/s, and will then plan and execute three iterations, with appropriate reviews and retrospectives, to shape the direction of the product.

= = = = = = = = = = = = = = = = = ======================

So at every conference I have been to I am handed a bag that contains stuff: brochures, key rings, pens, executive toys… and some horrendously ugly tee shirt or sweat shirt thing that would cause the fashion police to make an immediate arrest if I were ever foolish enough to wear said article on the public streets. Enough! It is time to take our ugly conference clothing and create items of fashion and originality, clothing we can be proud to wear in public.

FIT is a framework that comes in various guises (Fit, Fitnesse, Fitlibrary), and can be used in different ways. The core principle behind writing FIT documents is to promote better communication between the stakeholders of a system. In principle, using FIT is a good thing, but in practice we find that some teams struggle to use FIT documents effectively. In this tutorial we will introduce some concrete examples of poor FIT style, and get the participants to refactor these examples to improve them.

By attending this session, you will:

It’s easy to write software. It’s harder to write software that’s simple, elegant, working and important. Examples help to drive conversation, avoid ambiguity, eliminate waste, make estimates more accurate, clarify design and produce software that matters. Participants will develop a small game in a Renga (taking it in turns), adding examples of desired application behaviour at both a system and unit level, while learning BDD concepts.

Projects that fail do so mostly because they build the wrong thing, not because they do a bad job building whatever they do build. A big part of the difficulty is getting the users to tell us what they want. Traditional requirements engineering approaches have had mixed results, but requirements capture through “checked examples” (eg Fit -style tests) seems to work very well. Why should that be? Are there clues to be had from post-Aristotelian notions of “category” in the cognitive sciences? If so, how can that help find better examples?

This is a follow-on from a reasonably well-received talk given at Agile 07.

The session will be a work-torial. Or possibly tut-shop.