Author Archives: Anne-Marie Charrett

The Buzz On Testing

We’re witnessing a revolution my dear comrades. The tide is turning on drone testing  The word is out. Skill Matters!

Classes such as Rapid Software Testing (developed by James Bach and Michael Bolton), Just in Time (Rob Sabourin) and Elizabeth Hendrikson Exploratory Testing classes are becoming more popular.  They say “Test is Dead” but I say “Bad Test is Dead”.  Hurrah!

Slowly the realisation that tester’s need skills as such as bug recognition, critical thinking, the art of questioning, influencing and developing strategies to help them effectively test software.

I have a theory that the majority of tester training has been focused on process and documentation because its easy to teach that way. Instead of having to working on skill you simply point to a structure and say “follow that”.

Its much more challenging to develop a tester’s skill.

Skilled people earn respect and rightly so. We admire a skilled musician – even if the music doesn’t appeal to us. Developing skill is hard work. It’s the accumulation of understanding, practice and application. This takes time and effort.

As someone who has worked in the industry for twenty years, I know how hard it can be to allocate time for training. We’re deadline orientated and rightly, a Test Manager’s goal is to complete ‘good enough’ testing with the time and resources available.

Coaching is the antidote to this. It allows the tester breathing space to reflect and work on their skill.

The coaching I perform focuses on developing skill through understanding & practice. It takes into account the testers skill base, context, aspirations and the challenges a tester is facing in their current work.

As opposed to arbitrary training, coaching complements a working environment, and often the problems worked on are those that exist at work.

In conjunction with James Bach, I’ve developed systematic approach to coaching a tester’s skill. This approach is a result of coaching hundreds of students, evaluating transcripts and refining the coaching model.

It’s this model that I will be teaching in my workshops on coaching testers. I’ll be holding a workshop in London on the 4th May, and one in Sydney on the 29th May (with James Bach).

Come and join me!

What drives your learning?

What drives people to take up my offer of free Skype coaching?

Most testers when asked give on of the following reasons:

1) they want to pass an exam
2) They are having difficulty at work and need to get over some particular obstacle
3) They want to test themselves
4) They want a particular question answered
5) They want to know more about a topic
6) They want to learn how to coach other testers
7) They want to become a better tester – topic irrelevant

Many come to coaching with a mixture of frustration in their work or because they feel disillusioned.

It we seems that for many,  testers need drivers and general discontent to push them into learning something more. Few testers come forward wanting to simply learn.

It’s not all that surprising. I myself have just completed a gruelling year of full time work. It’s hard to allow yourself time to reflect and pause when you hop from one crisis to another and when you do, its more likely to be related to the challenges your working on at the time.

But I really admire the the testers that come wanting to learn more. Willing to take a punt at contacting someone they’ve never met and ask them to be coached. I salute you!

What drives these people? Is knowledge some kind of drug to these people? Do they simply want to know more? Do they want to be the best at what they can do?

I think its important to understand this question as people who want to learn for the pure joy of learning have a major advantage over others. They continue to learn and grow despite the daily challenges around them. Its not the challenge or goal that drives them to learn, its the learning that drives them to challenge themselves.

Common external drivers are completing a project, passing an exam, getting a job promotion and getting external approval from others. But what happens when the inevitable happens and the goal is completed or the challenge disappears? What happens to your thirst of learning? Does it die away?

Does that tell you anything?

Removing external oracles (those things you judge yourself by) casts your thirst for knowledge in a very different light, but its not a bad light, its an honest one and it belongs to you.

I believe we have to own our own learning. Drivers to learning can often be short lived. Have a goal to become a test manager, only to discover you’ve plateaued?  I suspect your learning may be driven by goals.

Imagine a world where you can tap into this love of learning as some testers do. Imagine learning for the pure enjoyment of discovering something new. Feel the satisfaction of overcoming a hurdle you have set yourself.

These testers they have taken responsibility for their learning. They see it as a way to develop and grow themselves. Their oracles to learning are inner satisfaction and self respect. They shine with the confidence of owning their own learning.

So do yourself a favour, spend a little time identifying what’s driving your learning and ask yourself “how is that working for me?”

Post Note:

If you want an example of a tester that learns for the love of learning, read Pete Whalen’s post on Rising from the Ashes.

 

 

Speed Kills

Some of my testers have become embedded on a newly formed agile team. Its been a roller coaster ride for sure. Lots of fun, thrills and a few scary points in time where I thought for certain we were not going to make it, or we were heading in the wrong direction.

From a testing perspective, we were quietly confident. Our testing is exploratory by nature, and so it lends itself easily to being flexible and adaptable.

We’re testing before the acceptance criteria are developed by attending the workshop and asking questions about the upcoming feature, learning why its needed and what problem its trying to solve.

And when it comes to testing the feature, we all jump head first  into the deep end, swimming with long powerful strokes through the water of doubt and complexity and only surfacing for air to congratulate and high five each other on another completed testing charter.

Its been a wet wild ride, but not without some uncomfortable moments.

While we’re revelling in the warm waters of upfront information and involvement, we’ve also noticed the cooler waters of reduced timeframes. Shorter iterations has placed a lot of pressure on the testers. There’s a feeling that we’re unable to pause and reflect during our testing, the pressure to be done within the iteration lends to the temptation of minimalist testing.

We had to change something to make sure we were testing well enough.

So, we slowed down.

We made sure we spent time to think critically about our testing, coming up with test ideas, understanding what done meant, and most importantly sharing these ideas with each other (including developers).

Now we test like this:

We still jump into the deep end, splash out, learn some stuff about the product but before we continue with some serious swimming we stop and confer. We reflect on our learning so far, we discuss our ideas and how we know we are done. Only then do we continue with our swimming, our strokes confident and strong.

Its been a revelation for some testers that are new to exploratory testing. They thought the objective was to test as fast as you can without stopping for a breath.

We still have the same time pressure on us, but that stop, that moment of pause and reflection has been sufficient to gain confidence in our approach and confident in delivering the best testing that we can.