What drives your learning?

Posted by on December 30, 2011 3 comments

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

Posted by on December 13, 2011 1 comment

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.

 

 

Coaching your Test Team

Posted by on November 26, 2011 No comments

I’ve implemented coaching within my test team. To me, this is a natural progression from the coaching work I’ve been doing on Skype.

Its early days yet, but I can already see the power of this approach to upskilling testers in a team environment.

I’ve been working on implementing coaching into my team for a while now. I was a little cautious on how to approach coaching in a work environment because the dynamics are a little different.

When I launched the program within the team I made it clear that:

1) Coaching was optional, its not mandatory .
I made this clear because its better that the tester owns the learning. I want them to feel they are in control of their learning. No-one is forcing you to be coached.

2) Coaching is not linked to performance reviews
I know this occurs in some organisations, but for my purposes I wanted to clearly distinguish between the two, so testers could feel they could discuss topics freely.

3) Coaching is focused on tester skill.
I wanted to make it clear I wasn’t a counsellor. This coaching was focused on becoming better tester’s improving skill. What the tester wants to learn and improve is up to them.

On the logistics side, I’ve booked a 1 hour session on a monthly basis for each tester. Initially, I blanched at putting this amount of time aside, but after some coaching, I’m convinced it’s worthwhile.

Its given me an opportunity to have a chat with testers I’m sometimes not fully engaged with. This is especially the case if a team lead is involved and I’m a bit distant from the tester. It helps me understand how the tester is doing, wether they are enjoying work.

It’s given me an insight into what tester’s want to learn about. I’m amazed how practical the questions are. In fact, it sometimes makes coaching a litter harder.
The challenge in coaching is not to answer questions but help them discover the solution for themselves.

I’ve adapted some of the approaches I use for Skype coaching. For example, I use tasks to help a tester understand the dynamics or complexity of a problem that seems simple.

An example of this was one tester who was frustrated at the lack of test procedures within the organisation. She felt sometimes she simply didn’t know if what she was looking at was the right or wrong answer.

I can empathise with this, especially, when your a young  tester working on a complex and technically challenging product. The simple answer here would have been to suggest she speak to a senior tester or stakeholder to find out more information. But I felt this wasn’t the real problem here. Even if you do have procedures, that doesn’t mean they will provide you with the full information. What happens if something occurred that was outside the procedure. Then what? Does it get ignored?

We ran through the calculator exercise, a challenge that Mr James Bach kindly allows me to use in my coaching sessions.

This really helped her understand the complexities of testing software and how we can’t rely solely on the information provided to us. Even then our job is remain skeptical of the information we are given. The tester had many questions and the hour flew by quickly. I summarised up what we had gone through, and suggested some further reading on some areas.

Time will tell if the coaching is really effective, but I left the coaching session with a clear sense of how powerful coaching an be in this environment . I see this type of coaching in testing teams becoming an effective tool in helping testers self learn.