PEST3: My testing exercise

The exercise I presented at the last peer conference (PEST3) November  24 looks like this:


Note: If you want to solve the puzzle by yourself, do not view the comments as these may contain spoilers! If you have thought of some solutions but want help with the rest of them, contact me on Skype (SkypeID: onlyonejerru). You can ask questions to get more information and keep figuring it out until you have covered the solutions I have listed. Please include an explanation in the contact request. Also, I  won’t answer immediately if I don’t have time, so please be patient.

Mission: Replicate the drawing you can see in the image above. Draw a circle and a dot in the middle of the circle so that you do not break the contact between the pencil and the paper, and so that there is not connecting line between the dot and the circle.

How does this help to teach testing? This exercise is mostly about asking questions about the assumptions one makes when they see it, and the courage to experiment. I initially had one solution in mind but this exercise actually gets people quite creative as I’ve seen. I think  I know around 5-6 solutions for this by now.

Yes, it is an exercise in the size of a snack. However, I guess a test lead can appreciate a small exercise to do with their team that won’t take too long, and that they can modify as well (I’ll write about this later).

Are you up for a challenge? Let me know how you would solve this in the comments. I’ll publish the solutions I know of later, and if you offer a solution I didn’t know, I’ll list it along with others (credit is due).

P.S. I have not restricted to conditions for the exercise to a great extent deliberately.


PEST3: Kickstart Learning by Teaching! vol1

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).