Our #TestBashNY workshop was Collaborative Exploratory and Unit Testing and we had a great time with our mob of 20+ participants. I feel that every time I teach in this format, I learn more and wanted to share a few of the insights that run through my mind.
I *see* you
For years, I've been running similar courses with individual and paired exercises. Comparing experience with those to the experience of running similar contents as mobs (one computer, one driver, group navigation through a designated navigator in strong-style), my chances of helping the participants advance in their skills are amplified.
In pairs, you learn from your pair. I, as the instructor, can't see you. I can see your results if I ask for a debrief. But I can't see you test. In a mob, I see the clarity of your thinking and your insightful approaches. I see the understanding of your purpose. I see if you have the structure and the focus. And I can jump in to give you experiences you wouldn't get without this.
Seeing more people test is giving me new motivation to find even better ways of teaching what I've learned through practice. It has brought me to ideas of teaching different level groups differently, leveling knowledge over time.
Instructor-Navigator
When there's a new concept to introduce, I can take over the navigation. I'm still playing with the ideas of when this is appropriate.
On the workshop day, Llewellyn took over navigation for finding the right place in code our insights from exploration were guiding us to add unit tests on, and creating appropriate seam to get into it. The participants took turns in driving, and supported his navigation as from the mob. This was a natural selection, when so many of participants did not identify as programmers.
In our previous version of the workshop, I took navigation while exploring by joining the mob while given constraints on what I was allowed to do: clean up the mind map and document things others had seen but missed, or what was still there hidden to be revealed to a tester eye. Showing the example to a group of non-testers changed how the others in the mob did the work. Examples of good work are powerful, and going through someone else's hands, the pace of going through them is more appropriate than in a demo.
Handling surprises
Since on this workshop we're turning insights of exploration into unit tests, there's a relevant element of randomness to what insights the group ends up producing in exploration. We ended up looking at automatic naming of elements in a list this time, and it was code we had not had to work on before. Thus we got to search the codebase for the right concepts, try out debugging to see if we indeed were where we wanted to be, go through series of refactoring to find the functional logic from the mess around it to get it under tests. I find the experience quite powerful, and the lesson relevant: after the half-an-hour of digging the functionality out, adding more tests was easy. The first takes most work, and enables them building variation on top of it.
Teaching more
This style of teaching made me want to teach more. It made me think how well this would adjust to company-specific trainings where we could explore your own application, finding problems, getting them under unit tests and fixed. If you might want to experiment on these with me and Llewellyn, please get in touch.
