I’m at the Conference for the Association for Software Testing (CAST 2026) this week, which has a workshop day followed by two conference days. This raises a question, What is a workshop, exactly? How does it differ from a conference talk? Which has better outcomes for actually changing outcomes back at the office?

After quite a few conferences, with a little bit of grey in my beard, I dare submit I am old enough to venture an opinion. You are welcome to disagree; after all, that is what the comments are for!

What is a Workshop, anyway?

I tend to think of Workshops as events where the participants generate the information. A tradition talk might be “We had this problem” (you may or may not have) and “took this approach” (that might or not  for you) and “had these results” (that might or not be what you are aiming for), while a workshop allows the participants to figure out what they should do, based on their own experience.

This brings me to the old consultant trick. With the consultants trick, you assume that someone in the organization knows the answer to the problem. Senior management bring you in, and you walk around and talk to people to get a better idea of the problem, along with some ideas for how to solve it. Some consultants bring in particular expertise, but what I call the consultants dodge is to expect that either (A) I can find someone who has the answer who for some reason does not have the ear of management, or (B) The organization will have a culture that prevents them realizing something that will be obvious to an outsider.

We see the same thing in therapy, where the therapists ask “… and what ideas do you have to approach that problem?” This is standard therapy (and ICF Coaching) thinking, which I call “The Swartz is in you lonestar.” And, as far as it goes, this is fine. If the therapist or coach gave the answer, that would just shift the person from stuck to dependent on the therapist. Instead they focus on helping the person figure it out for themselves. 

Workshops can take this up a notch. Group into tables by broad general problem category. Then write down your specific problem, then pass it to the person next to you, and solve each other’s problem. Then take those problems and solutions to the table. Then each table presents to the group.

Again, that’s fine, as far at it goes. It harnesses the experience of the group, which is likely to cover more edge cases than any individual expert. It is even better than the therapy game, as the group is larger and varied.

So why is it that these tricks and gambits stick in my craw so much?

It’s not that I am opposed to audience-answers-the-question workshops. Workshops are great. I like them so much that I explicitly run them as part of my own practice, usually with either Lean Coffee or an open space format. These formats get interested people around a very broad topic and set them free to go where they want to do – and they are formats where the organizers gives up any claim to expertise at all

So I suppose my concern is over a session called “integrating AI with your Continuous Integration framework”, where the speaker asks everyone to solve each other’s problems, and liberally everyone in the room says “yeah I don’t know to do that that is why I came to this session.”

See the problem here?

Earlier I said workshops needed to be some large meaningful percentage participant – but not 100%. If that is the case, how can we blend expertise with participation? 

Let’s talk about how I like to do it.

Teaching Concepts

For something like our lean software testing class, we interleave training and exercises throughout the day. This has pitfalls. When we started teaching the class, we allowed students to be on their cell phones or check email “Just don’t give us a bad review over your own choice.”

This, of course, never worked. Students would work through the presentation (45 minutes to an hour), then get to the exercise, be on the devices as we introduce the exercise, then not know what was going on, then need to hear it again. The day would be delayed, and, at the end, they would feel they did not get the value they had hoped.

The exercises themselves we try to do as realistic simulations. That is – we are pretending to write some software, but we’ll actually draw pictures instead. We are simulating a factory with variability in throughput, so these boxes represent work stations, and we’ll roll dice to generate throughput, and we’ll use these counters as widgets. Once we get down to actually writing software, we provide a skeleton software program with a test format (like a .csv file) and a blank method to fill in, in a language like Java or Ruby that can be understood by anyone.

At the end of the day, students have learned a concept’s name, received training on it, and conducted practical exercises on it. From there, we will end with a lean coffee session to figure out how to apply the idea back in the office. That wraps up a say, and makes the end of a one day tutorial. Our goal with a tutorial is to develop real, practical expertise in multiple dimensions that they can use back at the office. It is a big investment of time and attention, and it should pay dividends. (And the tutorial needs a clear enough explanation that if it does not apply, the description should help people realize that and not take the class!)

Everything above is for an external training event, at a conference or a public training. At a private event, we have a chance to do better. More than one day, cumulative, customized to the technology or software of the client. Best of all, on the last day, we can do an Open Space event where the whole class figures out a plan to implement new_idea.

Those are just my ideas on how to put together a tutorial or workshop. I hope they are helpful. If you have a different idea – hey – that’s what the comments are for.

Tomorrow

After the coronavirus global pandemic, everyone is traveling less, which means exercises over zoom, workshop materials you run without a facilitator, short workshops, teaching ideas over video and mobile apps – all kinds of things. That would be good grist for a comment, or perhaps, a post another day.

Today, I’m finishing off 3 days at CAST, tired yet reinvigorated to talk about testing and training.

If you’d like to talk, I’m around.