Tag Archives: software testing - Page 2

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.

 

On conferences and insomnia

Posted by on September 3, 2011 2 comments

For me, the sign of a good conference is insomnia the night after the conference.

Its as if my brain is unable to let go the new ideas and discussions I’ve had with other testers. Ideas that haven’t had an opportunity to be digested and reflected upon and usually around 2am after the close of a good conference my eyes snap open, my brain alive and alert ready for action.

Ideas and discussions from the day merge and meld into a boiling cauldron of fizzling synapse and bubbling endorphins and, as much as I try to breath deeply relax and let it all go, I know deep down its all pointless.

I’m going to have to get up and write down my thoughts and ideas.

STANZ Melbourne is one such conference and its given be a double dose of insomnia resulting in frenetic writing at 12, 2 and 4 am until finally my brain exhausted became compliant and allowed my poor weary body to sleep.

STANZ is sponsored and hosted by SOFTED. These folks at SOFTED really understand and ‘get’ software testing and it shows.

As well as  hosting this conference and getting some pretty impressive speakers in(I urge anyone who has the opportunity to hear Goranka Bjedov speak to do so) they also sponsor the Sydney Testers Meetup by supplying thirsty and hungry testers with drinks and nibbles at networking events.

Whats more they host peer workshops. The last one they hosted in New Zealand which was a huge success so much so that next year they hope to host one in Sydney.

Watch this space.

For me, STANZ gave me two core learnings.

The first was Goranka’s talk about the future of quality. I think this was really insightful and gave me much food for thought. The concept that quality is dead and that as testers we need to reflect how this will impact us. I’m not sure yet what this means for me(I need some more 4 am thinking on that one!) but  somewhere deep down, this struck a real chord.

The second re-enforced to me the power of sharing problems and getting ideas from your network of testers. In 30 minutes, Trish Khoo had a plethora of new ideas and suggestions for me to take away. Many thanks Trish.

Now off to order a double shot espresso….

 

Put your lips together and blow

Posted by on February 25, 2011 9 comments
lauren_bacall_and_humphrey_bogart_in_to_have_and_have_not_trailer

When I first heard about Tacit Knowledge, I had a vague idea what it was. The word “tacit” sounded a bit like “tactile” so I guessed it was knowledge that you could touch.

I was a bit off the mark.

Normally, I try to avoid starting my posts with definitions, it reminds me of those dreary debates we had at school where everyone started their discourse by using the dictionary definition.

I’m making an exception in this case as I think its important that we all understand what tacit knowledge is, so here is the wikipedia definition (Don’t be lazy, click on it)

This morning my son had a bit of a crisis going to school. As some of you know, we’ve moved country and continent. For my kids, this means new school, new friends, new environment. It can be a tough challenge for an eight year old.

Suffice to say, he needed a bit of cheering up, so I suggested he look on the bright side of life. Cue Monty Python Bright Side of Life

Well, it sort of worked especially when I tried to teach him how to whistle.

Have you ever tried to teach someone to whistle?

Lauren Bacall had a go, in the movie “To have and to have not”

But you know what? As Alex found out, if you do put your lips together and blow it doesn’t mean you can whistle!

Actually being able to whistle is pretty hard.(I’m sure many of you have memories of trying to whistle in vain!)

But why is it so hard? The basic facts were explained and it seems quite simple. What vital peice of information is missing from Becall’s instruction?

That my friend is tacit knowledge. Simply put, its the knowledge you can only learn by doing.

And so to software testing.

The reason why software testing is so hard to teach is because it requires the student to learn by doing.

To learn software testing you must….software test!

Yes, you can read and learn the peripheral stuff around testing. For example you can learn what a IEEE829 test process is. You can learn how to write a test plan, how to create a test script, but that is not testing.

Testing is the doing bit. The bit where you have to think, judge and act on a testing dilemma. Thats why some companies when interviewing for testers will ask you to test something. They know, intuitively, that testing is about doing, not writing.

My Skype coaching sessions on software testing are based around this principle. You won’t find me “sharing my experience” in the sessions because that’s not how you learn about testing. Instead, you get a challenge, puzzle or dilemma that I work through with you.

To really understand testing, you must do testing but also you must be aware of what you are doing while testing. Why? Because awareness brings about discovery. You discover assumptions you make in testing. You discover conflicting ideas and you discover your bias in testing. From that awareness comes learning and improvement.

I think thats pretty damn cool.

Now all together…

“Always look on the bright side of life…”

(my skype coaching sessions are free, contact me on skype id charretts with the word coaching in the request)