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.

Rediscover your inner tester

Linda Wilkinson in a recent post called on ‘Experts’ to come down off their ivory towers, and get back in touch with the rest of the ‘hoi polloi’.

Ivory Tower

Ivory Tower

It got me thinking about how in one way or another, we all have an Ivory Tower in testing which we can brag about. Your Ivory Tower (if its anything like mine!) is a nice place to be in. 



We can sit back and feel comfortable there, we know what we are doing and people treat us with certain level of respect.  No-one decided in advance to build these towers, but over the years, as we have specialised, it has become an area we have decided to call our own.


Some Ivory Towers I’ve come across in sofware testing are:

  • The Methodology Tower

    Over the years one process or methodology dominates and closes our minds to  new approaches such as Agile or Exploratory Testing. Or, we are so won over by Agile, that we fail to explore other avenues that may be of benefit.

  • The Trainer’s & Speaker Tower

    After many years of testing at the trenches, the experience acquired is used to help other testers by training and speaking in conferences. Gradually, the speaker/trainer looses touch with the tester on the front and starts finding it hard to identify with issues testers face on a daily basis.

  • The Management Tower

    Climbing up the corporate ladder, the Test Manager spends most days, managing people and projects. Their goals and challenges differ from the tester on their teams. They too start to loose touch on the real issues that testers face.

  • The Manual/Automation Tower

    As a tester, perhaps  whilst performing other tasks, perhaps you have decided to specalise in only certain areas? Manual testers, when did you last try out automation or performance testing?

There is nothing wrong in specialising, or having a niche. But in building these towers, how far have you wandered from the path of testing? You know, the actual testing, where you sit down in front of an application and well look for bugs?

In narrowing your skillset, I think you narrow your mindset, and consequently loose out on all the benefits that testing have to offer.

Puzzles and writing articles are good ways keep up your cognitive skills, but really nothing beats testing a product to remind of the real issues everyday testers face. Try getting your teeth stuck into a good testing problem, and remind yourself of the pleasure and heartache that testing can bring.

Puzzles and forum discussions will never replace or use the sheer number of skills you require in testing such as communication, negotiation, cognitive and written skills.

So, if you really want to get in touch with your inner tester get out and test. That doesn’t mean you have to give up your training or test management or what ever area you have chosen to specialise in, but there is no reason why you can’t contribute to some opensource testing, or volunteer to assist a charity in their software testing. If you can’t see your way to doing that, try keeping  the tester in you alive by going for the many testing challenges that seem to be popping up. I really like the Weekend Tester’s created by  Ajay Balamurugadas. They set themselves challenges and applications to test as a way of improving their testing skills. Matt Heusseur is another person who set a challenge on his blog.

Go on, I dare you to step outside and sniff the air outside your Ivory Tower and rediscover your true inner tester.

Will video kill the written bug?

I’ve recently finished some remote testing using exploratory testing techniques. I decided to test out a couple of new (to me) techniques. The first one was using Session Tester to track my effort. The other was creating short videos of difficult to articulate bugs.

First a bit about my testing approach. When I start this type of work, I tend to dive head first, perform analysis along side bug reporting. I then take a step back, work out a plan and get the client OK, then go back to testing. Finally, I write a report which includes recommendations, suggestions and naturally bugs. The reason I work this way, is I often get little up front information on the application, so I find the best approach is the “use it to learn it” approach. I tend to give myself a day to work out the application, and report back to my customer my intended plan.

Anyhow, I liked using Session Tester. It was handy to document the work as I went. However I found that it was hard to track my “tasks” with my bugs. I used my own numbering system which I could then link the bugs and notes. However, when I went to write up my report at the end of the testing, I found my notes were incomplete and sometimes hard to understand. Very frustrating when working to tight deadline.

Fortunately, as a backup to all my work, I always have SpectrePro running as I test. I do this because if a client comes back with a question, its handy to be able to go back and review the work I did. So, SpectrePro had captured not only the application under test, but SessionTester with relevant notes and bugs. It was very helpful to review the SpectrePro video in combination with the SessionTester notes and bugs I’d written.

Another concept I tried was to use FastCapture to capture video of any really difficult bugs. FastCapture allows you to capture your steps and add commentary to it. So if your good at describing what you are doing whilst you test, this is an excellent method to really explain to a client and or developer the problem you encountered. Watch out for the heavy breathing though!

My clients really like the video idea and wants me to explore it further. I don’t know if its something I would do for all bugs as its quite resource heavy (on my time and file size) however, its something I am going to persue.

Will video supercede the written bug? Perhaps not. Like the radio star of the eighties, I don’t think the written bug has anything to worry about. However as an additional testing and communicating resource, it has its place in the noughties.