During the last week I made some experiences using the material form the Accelerated Learning method. Motivated from the enthusiasm from my colleagues Stefan Roock and Henning Wolf, I read the book from Sharon Bowman about Training from the BACK of the room! The insights I got from reading it are great, and I was lucky enough to immediately apply them during training courses over the past week. Here are my findings about it, what I did, and what I might do in the future with the insights I got.
Accelerated Learning as taught by Bowman relies on the four Cs: Connnections, Concepts, Concrete Practice, and Conclusions. The connections are warm-up activites to get everyone talking about the topic, and what they already might know about it. This ensures that learners get familiar with the material, and start to think about the topic, and what they already know about it.
Warm-up activities that I found worthwhile for teaching Agile Testing and this thing we still call ATDD include having everyone walking around. At that time I ask them to tell someone else which they don’t know yet, what they already know about the topic, and which experiences they made.
Concepts involves everything that I might want to teach. For example, I create a jigsaw from the ATDD process on cards. I separate the artifacts created from the individual steps. The last time I used User Stories, Examples, Specification by Example, executable Specification, and Living Documentation as artifacts, and Specification Workshops, Refinement through examples, literal automation, and continuous execution as activities. Then I give participants five minutes to try to make some meaning out of it, and pin the cards in some order to a board. Since I didn’t explain too much about the content, participants so far didn’t manage to get the flow right. So, after five minutes, I go through the flow they pinned on the board, and then bring the cards in the right order. I think I will have to play with introducing the concepts first. And then letting participants bring them in the right order, might enable them to get this new idea right.
The third C involves concrete practice, something that I also talked about in my Alternative paths to self-education in software testing. For ATDD we focus on a practical course. That involves to write down some tests in FitNesse or Robot Framework, or Cucumber. In order to teach the content, and how to make up different tests, we work through some examples which are known to the group. By applying a methodological chain, I work from known concepts like decision tables as taught in the ISTQB courses to the decision tables as provided by FitNesse/SLiM. The unknown concepts of a query or a script table then are easier to get. The methodological chain is something I learned when becoming a swimming trainer. For little kids learning swimming, this is a great way to teach for example how to dive into the water head first. But that might be a story for another write-up.
Another concrete practice thing is to have people pair up, and come up with tests in pairs for a particular story. After that we collect them together. You can do this by collecting the results in the group, and going through each pair, or you can have the learners collect the results in a large mindmap on a whiteboard or flipchart as part of a concept map. While discussing the results, participants can learn from their individual tests as a group. When I think it’s time to discuss some trade-offs while coming up with tests, I ask open questions in order to get to facilitate the exchange among learners. One of the underlying principles from Bowman’s book is that whenever learners talk and exchange ideas, they are learning from each other.
The last C stands for conclusions. Conclusions are learner generated, and I try to facilitate not only what people take away from the training, but also to come up with creative ways to use the learned stuff in their daily work. At the last client I asked people to note down at least three ways they want to use what we discussed, and write them on a card. After that I asked everyone to turn the card around, write their name on it, and have people exchange their cards. Finally I asked them to report on their individual progress within the next month. Thereby learners make themselves accountable among each other. When learners make themselves accountable for incorporating their learning results into their daily work, then they are more likely to do so.
Lisa Crispin stated over twitter that she also read the book, but was unsure how to incorporate what she read into her trainings. I promised to write up an exercise that I used at a client last week, which she might also want to use. To start with I had everyone brainstorm different test techniques they know or incorporate into their work. Within the five minutes I gave the participants, I prepared the whiteboard with two axis according to the testing quadrants, that Brian Marick wrote down here. I labeled the x-axis with supporting the team on the left and product critique on the right. The y-axis I labeled with technology-facing on the bottom, and business-facing on the top. I then had the whiteboard separated into the four testing quadrants.
When the five minutes were over, I asked the learners to put their testing technique cards up on the whiteboard, thereby ordering them according to the testing quadrants. When they finished this, I discussed the techniques which were unknown to me. After that we talked about which tests they automated and which were run manually. Then we tried to put on some ranking on how many time is spent with each technique or activity. The group decided to use t-shirt sizes for this. This interfered a bit with the “M”s from manual testing, but in the end we found out the larger problems, which heavily influenced my next activity there-after.
So, using the Agile testing quadrants may generate insights into the team’s particular testing activities. We also got insights on where time might be spent too much, or what the problems for the team could be. While doing so, I introduced also the concept of the testing quadrants, and the discussion among learners helped to generate a deeper insight into the concept. Based on the experience, I plan to re-use this technique in the future as well.
Please drop me a note if you made similar experiences with teaching techniques. I would love to incorporate more collaborative learning experiences into my courses, since I truly believe in the technique. That said, when talking the next time about self-education in software testing, I’m going to teach it with some of these techniques as well.