Tag Archives: software testing

Training Testers

I’m having a complete blast at the moment adding the finishing touches to my upcoming workshops in Dublin,Belfast and London.

The Dublin and Belfast Exploratory Workshops sold out in a couple of days but there are still some seats on the coaching testers workshop in London. This is shaping up to be a great workshop – its jam packed with exercises and I’m very excited to be able to share with other testers the approaches that James Bach & I have honed over the past years.

Then its off to the inaugural Lets Test Conference in Stockholm where I’ll be giving a talk on coaching testers.

The Lets-Test conference is shaping up to be a huge event and personally I’m thrilled to be making part of history by speaking there.

Hope to catch up with you at one of these events!

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!

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.