Category Archives: software testing process

In pursuit of coaching excellence

When you coach a tester you’re working in an environment that dynamically changes as both the student and coach work through a coaching task.  If you look at the diagram below you can see all the different attributes that might change throughout a coaching session.

Also, throughout the coaching session, the student and coach have a mental model of the coach and themselves. They constantly re-evaluate these models as the coaching session progresses.

The coaching I do (and James Bach does) requires that the coach has a testing syllabus that they use to help the student. This is different to life coaching which is non domain specific. Also, our coaching is lot more directive. The relationship between the coach and student is more coach->student than the traditional peer-to-peer relationship you find in life coaching. I see our coaching more like sports coaching, where a coach outside of a game, runs you through drills and challenging exercises to help you improve, often without realising your in need of improvement.

Personally, I’ve experienced good and not so good sports coaches. In my school days I was a bit of a field hockey superstar (I joined the grade A hockey team two years ahead of time, making me the youngest player). My coach however was incredibly overbearing, shouting and yelling at us and telling us how hopeless we were. I’m not sure if we were hopeless or not, but I know we failed to win many games and left the season completely demoralised to the point I gave up hockey for four years. I was persuaded to pick up hockey again and this time we had a different coach. She was quiet, never said too much and let me play my free style. One day she came up to me and be a quietly suggested I move back 10 metres to be able to better angle my shots ( I was in a midfield position). Very quickly I realised the power of such a move, I was in a better position to be able to control the game. I was 16 when that happened and I’ve never forgotten the power of that one statement.

For me that’s what coaching is about and its the type of coach I aspire to be. Its directive but the direction is about the skill and how the student is performing that skill. Where its non directional is that I challenge the student to think for themselves. It’s paradox at play but one that works.

Its also powerful because it’s watchful, ready to tap into what a student is doing at an appropriate time, using pressure and energy as tools to make direction powerful to the student (just like my second sports coach did). The aim is to help the student feel empowered to achieve more.

But the energy is not only in one way. The coach is getting energised by the coaching session too. I’m constantly evaluating my coaching and testing ability. I become a better coach by doing this. My aim is to become the best coach I can be.

I can only do this by coaching lots of testers, evaluating the transcripts and also working with colleagues who inspire and want to become better coaches too. I’ve been doing that this week with James Bach. We’ve been working on our book on coaching, identifying ways in which we coach, syndromes that both student and coaches encounter (we need to do more of this) and also finding ways to better evaluate coaching transcripts.

I think an aspiration of excellence in any field is such a worthy goal. I was watching Ron Ben Israel who is a master baker of sugar dessert flowers. You can see his passion the how is pursuit of excellence has led him to create masterpieces in sugar. Who would have thought that you could become excellent in such a small field?

Excellence I think is different to perfection. Perfection to me sounds more absolute, perhaps a little unrealistic. Excellence however, is within my grasp but also always one step ahead of me. I can be excellent at one point in time, but I can always strive to be more excellent. I think this is a worthy pursuit and a good use of my time and energy.

What are you in pursuit of?

(if you want a coaching session on software testing, please contact me on Skype. My id is charretts, please include the word “coaching request”. I offer free skype coaching to testers as long as you’re willing to allow your transcripts to be used in my research and perhaps in the upcoming book. This means the transcripts may be published, though I do conceal the second name and any potentially sensitive data).

Crossing the bridge over no-man’s land

Indiana Jones in the Temple of Doom  has a “moment of indecision” when half way across a bridge he realises he’s been cornered by Mola Ram(the baddy) and his henchmen.

He looks back and there’s a hoard  of lusty savages baying for his blood, no luck there. He looks ahead only to find an equal challenge ahead. What is poor Indy to do?

Anyone who has introduced change into a corporate environment will empathize with his situation. You know the decision to break away from the past is the right one, you run eagerly and embrace change, only to find half way through the journey, your path to success becomes blocked.

I’ve been working with my test team for a while now moving from a process driven approach to a more of an Exploratory one.

Its not been without its challenges. Some concepts I’ve introduced have been welcomed warmly but the reception to others has been a little icy. In particular I’ve tried to move the team away from a test case management system. This was met with real concern and there was quite a resistance to the idea.

This troubled me as while I understood their concerns, I knew the system was limiting the generation of new testing ideas.

But how could I overcome this resistance? And really was it worth it? Perhaps the changes I had already made would be enough? The company was already more than impressed with the changes I had made so far.

I felt like Indy at the foot of rope bridge, how the hell was I going to solve this one?

So I stood at my crossroads and dithered. Oh God, did I dither. I ummhed and ahhed and pondered what to do. . But worse, I  knew my indecision was making the situation worse, and that the more I dithered, the harder it would be to rid ourselves of the dust bag of tired and well worn ideas.

Indy at this point, decides his only move is to cut the bridge leaving everyone to hang on for their lives.

Fortunately, unlike Indy I had a reliable and trustworthy sidekick.  Together, we setup a task force within the team to attack the problem. After some discussion we decided our approach needed four cornerstones. They were:

1) Creativity.

However we tested, our approach needed to enable us to foster and encourage creativity. With creativity comes new ideas, new models, new tests and so discover new bugs.

We’re covering this one with a number of approaches. One is to improve tester skill through practice and coaching. I’ve also created a folder of ideas for people to draw upon to help trigger new ideas.

2) Visibility

We wanted to be able to provide reporting on any testing we do. The reporting has to be simple yet with sufficient detail to ensure that our stakeholders understand what we have tested and why.

We have our trusty whiteboard which mostly hits the spot. We need to be able to pull up our actual testing including results in an easy to manage way. We’re looking into BBExplorer to handle that.

We will also track any essential test results on wiki in the form of a test report at the end of each iteration.

3) Coverage

We wanted to have some way of ensuring that key functionality/key features are always tested.

We most likely will rely on our test case management system for this, but we’re cleaning out all the dead wood and making the tests lighter and less authoritative.

4) Knowledge

We wanted to create a knowledge base. Our system is complex and it requires in-depth knowledge to test some areas. We want to store that information and knowledge. We also have a serious amount of test data we want everyone to be able to access, modify and improve.

We’ll use our internal wiki for this.

What I really like about what’s happened here is that the team came up with a solution to solve the problem. It’s a team decision which has got to mean easier implementation.

I think a couple of really powerful things have come out of this. I’m listing them here:

1) Change can be scary. Not changing is worse. Get on with it.

2) Use people around you to help bring about change.

3) Never lose site of your goal. This reminds me of Scott Barber’s email signature: “”If you can see it in your mind…you will find it in your life.”

I feel good. I hope my team does too. We faced a challenge. We examined it, questioned it and overcame it and we’ve all come out sharper, enlightened and positive about the changes ahead.

Now that’s what Exploratory Testing is all about.

 

A scrum in Croke Park

I’m attending the SQS conference on Software Testing in Croke Park, Dublin.  I thought it was appropriate to go to an Agile Testing session involving Scrum amongst other techniques in the same hallowed ground where not to recently a game of Rugby was played out between England and Ireland.

As our trainer Mike Scott was English, we tried not to gloat too much.

I won’t bore you with lots of analogies on how Agile is similar to rugby, besides after a day of Agile, I can’t think up too many, I’m sure someone out there can….

But here is what I enjoyed about Agile and its techniques

I liked the concept of the balloon pattern and testing so early that no code has yet been written, only your installation packages. I think thats really smart. You can iron out all your installation and configuration issues up front.

I like the concept that we as testers need to ask lots of questions and not make assumptions, though I think this is not unique to Agile.  A course on  Rapid Software Testing by James Bach also stresses this point.  However,  Agile demands intelligence in testing, where perhaps more traditional methods are less exacting?

There seemed to be a heavy dependency on Test Driven Development (TDD) which I am a big supporter of, though I do question the use of 100% Acceptance Test Automation.  I think in every software testing exercise there is room for both manual and automated testing. Its a question of intelligently planning out what percentage ratio works best for that particular project or environment.

Is Agile faster and cheaper as its sometimes portrayed?  I suspect not, but it does offer a customer greater flexibility and visibility and I like the sound of that!