Discovering Big Trak

Recently, I’ve been reading up on how we approach and report on solving problems. One book recommended to me was Exploring Science by David Klahr.

There’s lots in this book.  Khlar performs experiments in his “Discovery Lab” where participants are observed solving and reporting problems.  He uses a robotic toy called Big Trak. Its a self propelled, self contained toy that can be programmed to move around the floor.

Khlar programs a function (its a repeat function) on the toy. He then asks the participants to figure out the function and report how the program operates.

Its been an interesting read and some of the dialogue that happens during hypothesis and testing fits in nicely with the IM Coaching I’m giving. Its one of the reasons James Bach suggested I read the book.

This experiments were performed in the late eighties, so I was quite suprised to see Big Trak’s been sold in my local bookstore.

I immediately grabbed a couple and brought them home.

I handed one out to one of my kids to see if he could figure out how it worked. Here’s the video.

I’m going to incorporate these new robotic toys into my Exploratory Workshop, if I can just work out how to switch off that really annoying beep sound.

The pain…the pain

I’m currently experiencing a boundary test. The test is…how much toothache can I tolerate before resorting to as massive overdose of painkillers?

I know, I can feel you all wincing in empathy, even if you’ve never experienced toothache, almost everyone can empathize with the pain.

But……..

there is relief.

I am to visit the dentist tomorrow.

This story will have a happy ending. I know I will end up in less pain…eventually. I know the dentist is going to have to ask me questions and perhaps explore pain points. Bad pain points.

I also know its necessary for him to come to some sort of conclusion in order to help me.

I know its necessary, even if its hateful, cringe worthy and expensive.

Ok here it comes,  testing analogy…..

I love to explore. You probably love to explore.

But I love (and I suspect you do too) explore the bits I find interesting. I explore those bits that come naturally to me. Bits that I’m good at.

I have a tendancy (or bias) to ignore the bits I find dull, or that I’m not so good at…painful even.

Things such as tedious tasks, like examining behaviour I’ve already looked at.

Its important for me to do it though, I know to perform a thorough job, I have to examine areas I feel less comfortable in, areas that I have only checked, not tested.

Sometimes though, the pain is too bad. Its time to call in the expert. Someone who will do the job for me.  Like a dentist, perhaps?

Wish me luck…

Rapids Software Testing

As some of you know, I’m in the process of creating an Exploratory Testing workshop. It’s been a bit of a wild adventure, but hey, I’m clinging tightly to my oars as I hurtle down the rapids of ET adventure.

Have you ever been white water rafting? I have, and here’s a tip, don’t bother going if there is a drought.

Trust me, I learned the hard way on the Tully River in North Queensland. Tully is one of the wettest populated towns in Australia with an average annual rainfall exceeding 4000 mm (13.1 ft).

But not the year I went. I went when there was a drought and the water levels on the river had dropped.While the day’s outing was great fun, it never reached the hair raising exhilaration that I had anticipated.

It can be a bit like that in testing I guess.  If you want to have fun and be challenged, it helps to go where the water is deep.

Well I’m in deep testing water and I’m loving it! A day doesn’t go past where I’m not motivated to learn more and to challenge myself. To hell with the life jackets, watch me go!

Why? Because I’m learning something that is fundamental to any tester.

I’m learning how to teach  testing.

Precisely, I’m learning how to teach testing through Socratic Examination. This means, that I’m learning to ask the questions, pose puzzles and push students to struggle through testing principles so they come to a better understanding.

If this style sounds familiar, its because James Bach is teaching me this stuff. Its all part of this new coaching program which I’m aligning myself with. I will also be collaborating with him on a book he’s writing on the topic.

My experience on learning to teach suggests to me that this book is much needed. Practice is key to being a good teacher, but having a few strategies and heuristics to guide you along the way is essential too. This book will go some way to demonstrate that.

So what have I learned so far?

Lesson 1: A Mental Model

When working with a testing exercise you need a mental model of what you are aiming to teach.

Its not an easy task. There is no one strategy or model that fits all students. All students differ in their learning needs and in temperament. what works for one person, may not be suitable for the next, yet your mental model needs to cater for each individual.

You need to know your outcome, and where you are taking the exercise and still allow the student capacity to explore and come to some learning outcome.

I’ve noticed that James starts his coaching sessions with a mental test. He uses that to observe a tester’s thinking. He then frames his coaching session around a key thought or lesson, allowing  the tester to explore, yet always bringing them back to the intended final outcome.

All without one powerpoint slide.

I’m learning how to do  that too.

Lesson 2: Observation.

The coaching sessions may seem unstructured and ‘ad-hoc’, but as I mentioned there is always an underlying model or framework in use.  I’ve been observing some of these coaching sessions, and I’m starting to see patterns of behavior. I asked James about this and his comment was this:

Anne-Marie Charrett: When you are having these conversations do you consciously have an idea of the types of patterns you are going to use?

James Bach: Yes

James Bach: I’m trying to become more conscious of them and to make them easier to teach

James Bach: that’s what I’m using you for.

James Bach: we’ll learn them together

Observing patterns is essential to honing your teaching skills. Only through observation can you identify how you teach, what your natural strengths are or where you are biased. But also identifying patterns, helps you know what pattern (or heuristic) to use next.

Naturally, being taught directly by James Bach is helping a lot too. I think confidence in yourself is critical, both as a tester and a trainer. After all, how can you confidently explain your testing story if you have little confidence in yourself or what think you believe?

So that comes to lesson 3:

Lesson 3: A Testing Story

Teaching testing gives you confidence in your testing story. Yes, I read and study Exploratory Testing, I use Exploratory Testing. But standing up and talking about Exploratory Testing to me is the ultimate test in what you believe. If you can stand up and talk about testing, its a great boost to your testing story. Well , it is for me anyhow.

This confidence comes by first willing to put yourself in a vulnerable position, where you are willing to learn. It was only when I blogged about my difficulties about creating an ET workshop did help arrive.

It also comes through practice. I’m doing that too now, by blogging and testing out by challenges on fellow testers. I’ve already asked a few of you to testing challenges on skype or IM. I need to practise my exercises and puzzles against a variety of people.

If you want to be part of the fun, skype or IM me. I’m happy for anybody to take up my challenges. I need practice to improve my skills.

There’s lots more I’m learning, most of which my mind has yet to digest and formulate into identifiable ideas. But are you starting to see something here?

Teaching testing is very similar to testing itself, maybe a bit more intense…. like ET on steroids perhaps.  I strongly urge any tester looking to improve their skills to consider this option. Even if you never end up teaching formal workshops, the insights you get about yourself, the confidence it builds in yourself and your ideas in testing will stand you in good stead.

Footnote.

I value your thoughts, in particular if you disagree, or question what I’ve said. Every discussion on this helps me refine and consolidate my understanding on the subject.

reinventing the wheel

I liken my experience of creating an Exploratory Testing workshop as similar to recreating the wheel. It would be easy to copy someone else’s version of a wheel, after all there are a lot of great wheels out there. Alternatively, I could create my own wheel.

But how do I do that? How do you improve on the wheel?

My feelings about holding such a workshop range from massive excitement to extreme anxiety as I grapple will the question, “What the hell am I going to talk about”?

I’m not talking about the content, there as been plenty written on Exploratory Testing and I could spend weeks just reading up on other peoples articles, notes etc. If I wanted to, I could re-regurgitate lots of excellent material on the subject. But I have a problem with that approach. In fact I have two problems (maybe even three if you take into account the massive attack of self doubt I had this morning!)  with that approach.

The first one is this.

How do you teach Exploratory Testing? As James Bach writes in his article Exploratory Testing Explained and something I WHOLEHEARTEDLY concur with (through bitter experience!) is that:

Among the hardest things to explain is something that everyone already knows. We all know how to listen, how to read, how to think, and how to tell anecdotes about the events in our lives. As adults, we do these things everyday. Yet the level of any of these skills, possessed by the average person, may not be adequate for certain special situations. Psychotherapists must be expert listeners and lawyers expert readers; research scientists must scour their thinking for errors and journalists report stories that transcend parlor anecdote.

So it is with exploratory testing (ET)

The second problem I have is that

If the workshop is going to be any good, I know it has to come from the heart, my heart.

So even if I was tempted to say take James Bach’s course and deliver it (anyone who takes his course has this permission, as long as credit is given) it would be pointless.  Because I know it has to be my story, what my understanding of ET is, not anyone else’s. Its one of the reasons why James’s course is so damn good. His conviction comes through because its HIS story.

As an exercise, creating an ET workshop is a great challenge. It demands the ultimate in story telling. There is nothing better to confirm/challenge your beliefs and/or understanding than to articulate it in front of a class.

There is also nothing more humbling. It makes you realise how much I have still to learn. As part of my effort in creating this course I’m reviewing  familiar documentation again. In particular James’s RST slides.Looking at these slides in a critical way has been very beneficial. Its made me question my depth of understanding of some of its content.

Its been a good morning though. I’ve made some baby steps and have got some ideas that I feel I can call my own.

I know that the workshop is to be practical, and I have a few ideas in mind on that. The challenge is to use the exercises to teach an ET point.

What the workshop(or the wheel) will end up looking like, I’m not yet too sure. One thing I do know is that as time evolves it will become more and more my own story and yes, my wheel.

Is document a dirty word in Exploratory Testing?

I went on James Bach’s Rapid Software Testing (RST) course because some of the concepts and ideas that I had read about exploratory testing and RST appealed to me.   I liked the idea that central to testing is a critical and context-driven approach and I also wanted to put intelligence back into testing.

I was curious though, as on some blogs I read it appeared that exploratory testing and traditional testing were mutually exclusive. You are either a champion of traditional testing techniques and provided multiple test documents or you’re in the maverick camp which threw out all documentation and just ‘tested’.

I was relieved to learn that for rapid software testing, this is just not true. I was relieved because I LIKE DOCUMENTS.  I like them because in certain circumstances I find them helpful.

Because I have to confess, sometimes I forget to test parts of an application. Even worse, sometimes I don’t want to test the hard areas.  

A document gets me to test all areas and to test the parts that I really don’t want to test. It helps me remember the results of what I’ve tested because sometimes I need to know that information.

What James Bach reminded me, was that the ultimate goal of testing is very simple. It’s to test an application with intelligence and thoughtfulness. The goal is not to create endless documents on testing.  Instead, documents can sometimes be handy tools to assist you in testing.

I don’t think I will ever totally give up on my documents. They are my friends. However, I will make sure that in future, these friends can stand the test of relevance, accuracy and brevity.