[an error occurred while processing this directive]

exampler.com/testing-com > Test Patterns > Workshop 1 > Schedule [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Schedule, Including Preparation for You to Do

In the text below, things for you to do before the workshop are tagged with TODO.

Day 1

Day 2

Day 3
9-12
Introduction. Presentation by Brian Marick on what aspects of patterns he finds most useful and appealing. Agenda check. Discussion of what we hope to accomplish.
9-12
Possible short demo of pattern writing.
Description of what to do next; discussion of possible templates to use.
Pattern writing.
9-12
Some might continue pattern writing.
Some might have their new patterns workshopped.
Some might want to begin organizing groups of patterns (moving toward a pattern language).

Lunch (on site)

Lunch (on site)

Lunch (on site)
1-5
Pattern reading ("workshopping") in groups of 5-8. We will read selected pre-chosen patterns.
1-5
Continuing pattern writing.
Discussion of what we just did.
Planning for tomorrow.
1-2
Wrapup; what should we do next?

Introduction

We suspect people will come to the meeting with various preconceptions about patterns, and that it will be useful to air those right at the beginning. As a springboard for discussion, Brian Marick will air his preconceptions. He'll base those on 8-9 years of attendance at Ralph Johnson's Software Architecture Group, where we've read and discussed lots of patterns, and on the following books.

TODO: You needn't read any of these books before the meeting. However, I recommend you look at Brad Appleton's "Patterns and Software: Essential Concepts and Terminology" or James Coplien's "Software Patterns Management Briefing". Both are long, but both are nicely set up for skimming. Please also take a look at Doug Lea's Patterns-Discussion FAQ.

The Timeless Way of Building, by Christopher Alexander
This book, on the architecture of towns and buildings, has inspired a lot of software patterns work. The first few chapters, which could be caricatured as being written in a very 60's style, put some people off. If that happens to you, skim forward until you hit chapter 14.
A Pattern Language, Christopher Alexander et. al.
This book contains 253 specific patterns for building towns and buildings.
Christopher Alexander: The Search for a New Paradigm in Architecture, Stephen Grabow (out of print)
Woven together out of interviews with Alexander, it covers work done since the previous two books.
How Buildings Learn, Stewart Brand
A discussion of how buildings change over time. Not specifically about patterns, but definitely coming from the same attitude toward architecture, building, design, and change.
Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma, Helms, Johnson, and Vlissades
This is the book in which Alexandrian ideas (with modification) hit the mainstream of software development. You pretty much need a reading knowledge of C++. (There's a Java translation I haven't read.)
Pattern Hatching: Design Patterns Applied, by John Vlissades
Further ruminations on the topics of Design Patterns.
SmallTalk Best Practice Patterns, by Kent Beck
A set of patterns intended to transmit some of the lore of the expert SmallTalk programmer. Not understandable unless you have read at least a few chapters of a SmallTalk book.
Patterns of Software, by Richard Gabriel
Gabriel considers in detail certain aspects of Alexander's writings. His notion of "habitable software" is particularly interesting.
The "PLoPD" books
Collections of papers from the Pattern Languages of Programs conferences.

Here are some sources for testing patterns:

There are a few other test patterns in Linda Rising's The Pattern Almanac 2000.

Pattern reading

The patterns community has evolved a certain style of critiquing patterns and groups of patterns. It's based on writer's workshops.

TODO: read at least the short summary titled "How to Hold a Writer's Workshop". We strongly recommend you read the longer "A Pattern Language for Writer's Workshops", by James Coplien.

TODO: we will need two volunteers to be workshop moderators. Volunteers should read the Coplien patterns linked to in the previous paragraph.

Note: many of us at this workshop come from a more rough-and-tumble tradition of critiquing. It may seem from the readings that there's no room in writer's workshops to drill down usefully into the content of a pattern. Two comments:

  1. The format works better for that than you might think.
  2. We will adjust the format as appropriate. (For example, the Software Architecture Group meetings are blunter than the PLoP workshops, largely because we often review drafts of books by seasoned authors.)

We will begin the pattern reading session with a short demonstration.

TODO: Before the workshop, tell Marick which of the following documents you'd like to read and which you do not want to read. He'll organize people into two or three groups, each of which will workshop one of the documents. (Everyone will also workshop the Meszaros and Doble paper linked to in the next section.)

Note: some of these are biggish collections. Don't worry about that - you won't have to talk about every pattern in a collection. You won't even need to read every pattern.

Pattern writing

TODO: Read "A Pattern Language for Pattern Writing", by Meszaros and Doble. Consider also reading the shorter "Seven Habits of Successful Pattern Writers", by John Vlissades and "Tips for Writing Pattern Languages", by Ward Cunningham.

Here are ways other people do small-group pattern writing. We're going to use a combination of the Manns and Hanmer styles, plus a little bit from the others. Details at the workshop.

Possible topics

What topic area can we (or a subset of "we") put continuing effort behind? Here are some possibilities:

Test planning at the individual level
Often, it seems that individual testers are told "spend two weeks doing 'functional testing' on 'Account entry'" and left to figure out what that means. How do they decide what things to do? in what order?
Test planning at the group level
A lot of people are stuck thinking that one size (IEEE829) fits all. Even people who don't think that tend to flounder as they try to figure out how to compose many reasonable ideas about who should do what, using what, and when. Group-level test planning seems to match well the sort of evolutionary activity that the original Alexandrian patterns work favored. Does growing a test plan over time have the same "feel" as growing a home over time?
Test automation system architecture
People using test automation tools need a strategy (capture/replay? scripted automation? scripted frameworks with captured sub-actions? data-driven automation?), and they need to build and deploy and explain libraries of support code. This is classic patterns territory: Design Patterns started off as notes toward an "architect's handbook". So this might be a low-risk route to take.
Programmer testing
Programmer testing is a fairly hot topic these days, due entirely to Extreme Programming and Fowler's Refactoring. There's a lot of discussion, and a lot of wheel reinventing - which makes this prime territory for pattern mining.

We expect discussion of this to thread through the workshop, especially as we separate into groups to brainstorm patterns (the first step of our pattern writing).

[an error occurred while processing this directive][an error occurred while processing this directive]