Category Archives: insight - Page 2

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.

 

An affidavit of sorts

The last three months I’ve worked specifically with the goal of my testers taking responsibility for their work.

I’m a strong believer that each person is responsible for their own lives. I try to  live by it and I expect others to do the same. Its one of the reasons why I endorse and believe Exploratory Testing is so powerful. The tester becomes centre to the testing. The tester is the decision maker responsible for their decisions(good or bad) and must be willing to stand by their choices and defend them where necessary.

Its a powerful concept, and I think somewhat alien to the way we are brought up and perhaps bring up our own children. Instead we are protected or we try to protect, wanting to prevent harm to those we are close to. Actually, I think its impossible to totally protect people, much better to teach survival skills.

I often hear people saying: “A great test manager removes obstacles so that their team can test” and its true. A good test manager will do that. However, I think a good test manager will also allow their testers to fail. Allow them to make their own decisions and learn to stand by those decisions and then defend them.

If we don’t do that, are we really helping testers to learn and grow?  I wonder.

I’ve had the luxury of procrastination over the past two days. Yesterday, I spent a glorious few hours at the Seattle Art Gallery. It was the perfect antidote to CAST 2011, which was exceptional yet mentally exhausting.

I also missed my flight back to Sydney, which meant I had a second day of whiling away hours at Seattle airport.

Our brains are so fascinating, aren’t they? Just as I’m about to board the flight, a burst of insight and determination hit me. I guess all that procrastination culminated in my powerful thought.

Its this.

As we learn and grow as testers and human beings, we constantly need to revisit our beliefs, values and motivations. I realised mine needed a revisit. (Incidentally, my tutorial at CAST was on this topic, another example of “if you want to learn something, teach it!”)

I needed to rework my ideas, goals and what was important to me. I needed to put myself in the centre of my testing career. I’m responsible for what I do and what I learn. Me. No-one else. Not mentors, not other testers, not thought leaders. Little ole me.

A few testers at CAST really inspired me to be like this. Unfortunately, I don’t know their names or else I would cite them here. But they’re not thought leaders or mentors, they’re context driven testers with a mind of their own. I like that.

I’ve always been able to think for myself but sometimes, you just have to up the anti, you know?

I don’t know what this will mean for me. I’m not sure where it will lead. What I do know that from this point on, I will continue to own my decisions and I will stand by them, just as I encourage my own testers to do.

I guess thats it. Its just something I wanted to share with you all.

QED

Where do I go from here?

In two months to this day, I will be giving my tutorial on Career Management for Software Testers at CAST 2011, in Seattle, USA.

Any self respecting software tester has asked themselves at least once in their career. “Where am I going with all this?” or “Is this role really where I want to be for the next x number of years”?

If you look around, its traditional* to think of a software testing career path as follows:

[quote style="boxed"]At entry level as a Tester, you’ll primarily be performing test execution and acquiring niche skills to ensure systems meet performance standards required by the business and end-user.
Progressing to Test Analyst and then on to Senior Test Analyst, you’ll work on more complex scenarios, become involved in requirements analysis and test case design as well as execution. As a Test Analyst you’ll also be able to become involved in the specialist areas of Test Automation and Performance and as a Senior Test Analyst you’ll start taking responsibility for junior staff.  [/quote]

I think that’s a real shame that the role of  Test Manager is considered the pinnacle of your career. Why is it that in order to advance your career you have to be seen to me leading people?

So, I want to show testers that there are other career paths. In my tutorial we’re going to take a look at some of the typical roles testers in testing;  That of a tester specialist, a test manager and a test consultant.

But you won’t have to listen to me share about it, I got some fantastic software testers who have agreed to come in a share their own personal experiences. Karen Johnson (Test Consultant), Fiona Charles (Test Manager) and Markus Gärtner (Software Tester) will be available to discuss the pro’s and cons of their respective roles and understand what skillset you may need to get perform these roles.

I’m looking forward to giving this tutorial. Why not join me at CAST 2011? There are still some spots available.

*sourced from Planit website