Tag Archives: process

Crossing the bridge over no-man’s land

Posted by on September 22, 2011 6 comments

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.

 

Rediscover your inner tester

Posted by on October 21, 2009 5 comments

Linda Wilkinson in a recent post called on ‘Experts’ to come down off their ivory towers, and get back in touch with the rest of the ‘hoi polloi’.

Ivory Tower

Ivory Tower

It got me thinking about how in one way or another, we all have an Ivory Tower in testing which we can brag about. Your Ivory Tower (if its anything like mine!) is a nice place to be in. 



We can sit back and feel comfortable there, we know what we are doing and people treat us with certain level of respect.  No-one decided in advance to build these towers, but over the years, as we have specialised, it has become an area we have decided to call our own.


Some Ivory Towers I’ve come across in sofware testing are:

  • The Methodology Tower

    Over the years one process or methodology dominates and closes our minds to  new approaches such as Agile or Exploratory Testing. Or, we are so won over by Agile, that we fail to explore other avenues that may be of benefit.

  • The Trainer’s & Speaker Tower

    After many years of testing at the trenches, the experience acquired is used to help other testers by training and speaking in conferences. Gradually, the speaker/trainer looses touch with the tester on the front and starts finding it hard to identify with issues testers face on a daily basis.

  • The Management Tower

    Climbing up the corporate ladder, the Test Manager spends most days, managing people and projects. Their goals and challenges differ from the tester on their teams. They too start to loose touch on the real issues that testers face.

  • The Manual/Automation Tower

    As a tester, perhaps  whilst performing other tasks, perhaps you have decided to specalise in only certain areas? Manual testers, when did you last try out automation or performance testing?

There is nothing wrong in specialising, or having a niche. But in building these towers, how far have you wandered from the path of testing? You know, the actual testing, where you sit down in front of an application and well look for bugs?

In narrowing your skillset, I think you narrow your mindset, and consequently loose out on all the benefits that testing have to offer.

Puzzles and writing articles are good ways keep up your cognitive skills, but really nothing beats testing a product to remind of the real issues everyday testers face. Try getting your teeth stuck into a good testing problem, and remind yourself of the pleasure and heartache that testing can bring.

Puzzles and forum discussions will never replace or use the sheer number of skills you require in testing such as communication, negotiation, cognitive and written skills.

So, if you really want to get in touch with your inner tester get out and test. That doesn’t mean you have to give up your training or test management or what ever area you have chosen to specialise in, but there is no reason why you can’t contribute to some opensource testing, or volunteer to assist a charity in their software testing. If you can’t see your way to doing that, try keeping  the tester in you alive by going for the many testing challenges that seem to be popping up. I really like the Weekend Tester’s created by  Ajay Balamurugadas. They set themselves challenges and applications to test as a way of improving their testing skills. Matt Heusseur is another person who set a challenge on his blog.

Go on, I dare you to step outside and sniff the air outside your Ivory Tower and rediscover your true inner tester.

I’m glad I’m not a piece of software

Posted by on October 20, 2008 5 comments

I joke about my personal development lifecycle (PDLC) as my work in test management often requires consistency & repeatability in the form of a test process. In comparison my own PDLC is often very erratic and ill behaved. In fact its not really a typical lifecycle at all except perhaps that I was born and one day I will die.

My family and I have recently decided to spend some time in Ireland. In November, we are uprooting our family in Melbourne, Australia and dumping ourselves back into a very sodden, albight green sod of turf known as Ireland.

We are doing this without any certainty in jobs, schools, long term accomodation etc and its making me extremely nervous. To make it all the more uncertain, the world has decided to have a global financial crisis. My faith that all will work out is being severly challenged!

As I  continue along my PDLC, my outlook on life has changed. What would have once been an adventure is now looking like a torturous test.

So I repeatably breath my mantra, “it will work out, I will find work in Ireland” . Who says life is dull?

Anyhow, back to software testing and lifecycles.  I suppose the difference between software and people is that we own our lifecycle and thankfully we get to choose how our life turns out.  We can choose to make it unpredictable and we can behave outside a given setup of expectations.  So even though my life at the moment is in turmoil, its my turmoil. I’m glad I’m not a piece of software that has to follow a rigourous testing process, in order to live up to someone’s expectations.