Last weekend I had the pleasure of presenting at PEST3 (third Estonian Context-driven Testers’ Peer Conference). The theme for this peer conference was focused on teaching testing. In addition to the presentation, each participant had to present an exercise for teaching testing. This “added bonus” turned out to be pretty fun for me at least.
So what was covered? Here’s the first part of my summary of the presentations.
Risko Ruus talked about how he taught management that things can be different and how he had to do his share of learning in the process. In his case, it appeared that the motivation to learn more came about when he was asked to work on his idea of a test tool to be used for smoke tests. As he admitted, his motivation had been sinking as his duties at work very quite routine and tedious most of the time. So when the opportunity was there, he took it and started teaching himself about programming to create the tool. Once the proof of concept was ready, he successfully sold the idea to management. I must say he has some mad salesman skills or the management happened to be able to grasp the idea without much difficulty 🙂 In any case, he could proceed working on his tool.
What he pointed out was that he always kept in mind the fact that he knew he was going to give the tool to other people to use. This forced him to think about teaching the future users and keeping everything simple and modular.
Eventually, he other team who got their hands on the tool got a bit carried away. Risko explained that they wanted to immediately broaden the scope and start using the tool for things that… Risko hadn’t planned. So here goes another point for teaching using a tool: be very clear and firm about the scope of your teaching. Listen to what your students say but don’t hatch a new plan or solution along the way. Managing the expectations is also a big part of successfully teaching someone.
Risko had a fun testing exercise, namely, juggling. So what does juggling teach you? Consistency, breaking down a complex activity. Risko also said he uses it for defocusing: it’s a good incentive to use in order to drag your butt up from the chair, move around, and give your mind a break. So you’re doing something physical and your mind is concentrated on juggling. But we all know how this works: you’re dealing with something on the surface while your mind solves some issues in the background. This is how the heureka! moments are born.
Aare Nurm talked about coaching and SBTM. I really was one big ear because I’m interested in hearing about the experiences with implementing SBTM. I’ve been fidgeting with the idea and we occasionally apply this but I haven’t commited to SBTM just yet.
Fortunately, a lot of what Aare was talking about had a familiar ring to it. Important points I took note of:
- he uses the debriefing session for a different function depending on context. For novice testers, it’s a coaching session. For experienced testers, it’s a learning session where he studies their minds and their test results.
- getting the size of the session notes right is a difficult task at times. How much is too much or too little? His criteria were that the session notes are sufficient if all of it can be covered during debriefing (if something is left out – too much; if something needs to be checked – too little) and one has to be able to tell what they tested in a couple of weeks’ time.
- Debriefing may turn into a brainstorming session and this is OK. It is my personal experience that these sessions easily become productive discussions. I haven’t tried to hold it back because I see a lot of good coming from this. I was glad to hear that someone has a similar experience.
I still need to figure out a bunch of administrative things before employing SBTM but I got a few simple but solid ideas that can help me.
Aare’s testing exercise was a sudoku. I haven’t really solved sudokus… I just haven’t picked them up. Aare, of course, gave us just a couple of minutes to solve this. Aaarghh… Well, I got a bunch of numbers right at least. I spent some time trying to figure out the strategies to use: I looked at number of digits in a row/column; how many numbers were in one 3×3 box and which number would most definitely match etc). Well, I guess if I practiced and found more strategies, I’d also become a better… sudoku solver 🙂 Though when talking about teaching testing, sudoku may be good for recognizing patterns, learning to use a proper strategy quickly (especially if you put yourself under a time constraint).