Tag Archives: Exploratory Testing - Page 3

Are you a Buccaneer Parrot?

Posted by on April 30, 2010 9 comments

I’ve had a couple of ‘epiphanies’ this morning and consequently have that weird floaty, happy/anxious feeling that I get at moments like this.

Courtesy National Geographic

I didn’t go to StarEast but I, along with countless other software testers have been watching the virtual show through twitter.

Some of it I let go, but a couple of links I’ve clicked on to see what all the fuss is about. Boy, if the two links I clicked on are anything to go by, it would have been a great event to be at.

The first seismic changing event for me was listening to James Bach’s clip on what it means to be a buccaneer tester.  Now James is a tester that I have mixed feelings about. I went on his RST course a few years ago and really enjoyed it. I loved his FOCUS/DEFOCUS heuristic and its one of my key techniques that I apply when I test. BUT, sometimes I find his style can be overly aggressive, especially when it comes to:  oh crap, here I go, CERTIFICATION.

But not today. Today he was sublime and this key point hit me:

“We have got to be testing from our own place, not copying like parrots”

This resonated heaps with me as its a trap that I constantly fall into.  Now, I pride myself on my software testing skills. I do have a fondness for exploratory testing and have a knack in asking the ‘right’ question when determining context. Here’s the crunch though. I call my approach pragmatic. In other words, I DONT ROCK THE BOAT.

So when asked, I will happily manage a team of scripted testers. Why? Because that is the process. That is how things are ‘done’ in that company.

This creates a dilemma for me, because it leads me to ask what in  software testing do I really believe in? Where is my “own place”?   To what lengths would I go to ensure Exploratory Testing was used in a team I led? (I know I would never personally create a test script, or follow one for that matter). This is pertinent to me because I’ve just gone for a test lead role that requires ‘strict adherence to a process’.

In order to be able to answer these questions, (and writing this post is helping me decide mine) and as James puts it ‘test from your own place’, y ou have to know where and what “that place”  is. The only way your going to find it, is by taking a stand, having an opinion, suggesting a new approach and being prepared for people to disagree with you.  To quietly agree(or disagree) is not going to help you know what you believe in.

It’s funny you know, I’ve always thought that being outspoken is such an ‘American’ thing. We ‘Europeans’ are way too polite to express our views so, well, blunt. Perhaps there is an element of difference in culture, but I don’t think I can hide behind that excuse any more.

Here’s the great thing though,  when you find ‘your place’ you will be a lot more secure and that is going to help you become a better tester.  Why? Because being secure about your place means you don’t have to worry about what other people think. You are less fearful one thing I know for sure:

IF YOU FEAR WHAT OTHERS THINK OF YOU, YOU WILL NEVER BE FREE TO LEARN NEW STUFF

It kind of goes with Elizabeth Hendrikson’s article that says “Not knowing answers isn’t sign of weakness; not asking question is“  Being fearful of looking stupid, prevents you from asking the dumb question. By the way, before you pat yourself on the back about being able to ask ‘dumb questions” I believe its easy to ask the dumb question when your experienced in an area, but try doing it in a field where your not so experienced. It can be a real challenge.

And it can be a real challenge for experienced testers to ask ‘dumb questions’ when they want to appear knowledgeable. I think for wannabee experts this is a real trap. If you try and spend all your time looking like you have the answers,  you put yourself in a situation where you stop asking ‘dumb questions’

Why do I believe all these things, because its what I feel and do sometimes. No often. And its something that it going to change. Now.

So thats why James Bach’s Video resonates so strongly with me.

Thank you James, you have once again been instrumental in my growth as a software tester.

Arghh, what’s that pieces of eight, pieces of eight?

Holding the cat by the tail

Posted by on September 27, 2009 1 comment

I thought Jack Margo’s interview by UTest was very interesting. What caught my eye was the following statement:

The days of specialists are mostly killed from the recession…you have to be flexible and know multiple disciplines to exist in today’s dev environment.  In web development alone, you need to be proficient with XML, DHTML, JS, a DB flavor, an OS flavor, a programming language and some semblance of UI Design to even handle front-end.  I have friends who knew only HTML or only PERL.  They are struggling to say the least

It made me think  the same applies to us as software testers.

Have specialists in software testing being killed by the recession? Is it necessary for software testers to be ‘flexible’ and know ‘multiple disciplines’?

Personally, I think so. Its not good enough these days to be a ‘manual tester’ or an ‘automated tester’. Instead you need to be able to do both. I don’t think that means you have to be ‘expert’ on both, but it does mean you have to have knowledge of both and a good knowledge in one area.

That’s why I’m excited about Nathan Bain and the free automated testing sessions he’s starting up.  As he puts it:

Come to meet fellow testers, share stories and experiences about tools and techniques which may, or may not, have solved testing problems on other Agile projects.

This is also a place of learning, where live demonstrations of tools will be given for FREE – no more expensive training courses for simple (and free) open-source testing tools.

What a fantastic opportunity to learn about automated testing!

To complement this, Rob Lambert has setup some free Exploratory Testing Sessions.

Both organisers have mentioned that these sessions could also be performed online.

I am not going to miss out on either opportunities. I would encourage those interested to sign up to both, either to contribute so others can learn, or learn from someone else.

BTW: two quotes were in contest to head this post. The first one was by Mahatma Gandhi:

“Live as if you were to die tomorrow. Learn as if you were to live forever.”

The other was:

“If you hold a cat by the tail you learn things you cannot learn any other way.”

Mark Twain

I love both for different reasons, but I thought the second one appealed to me as a tester, hence the title :)

Do your bugs only glow when its dark?

Posted by on July 29, 2009 2 comments

Have you ever been in the situation where no-one else can find and repeat the bugs you find? Perhaps you have a canny knack of finding unusual bugs, or maybe it’s time to improve and update how you write bug reports!

I do a lot of offsite exploratory testing in very aggressive timelines and consequently I have to admit, I sometimes start making basic mistakes.

My common mistakes are:

1) I don’t write the bug report up straight away

2) My bug reports are not detailed enough

3) I underestimate the time it takes to write up defects

4) I don’t use a defect tool

You can imagine, when you’re working offsite without even meeting the developer, this can lead to all types of complications. So I need to put myself in that poor developers shoes and make my bug reports as clear, concise and as detailed as possible.

I think it’s tempting when there is little formalised structure in testing to overlook writing a disciplined bug report, but it’s worthwhile to you and the customer. I mean what’s the use of paying someone to find bugs when no-one else can find and fix them?

Anyhow to prevent myself repeating such unforgivable mistakes, I have developed a set of guidelines to follow.

Offsite Exploratory Testing Guidelines to Bug Reporting

1) In the estimate to the customer, make sufficient time to write your bug reports as you go. It’s impossible to know how many bugs you are going to find but you can do a bit of math. If you’re planning three    days of testing, and you find 100 bugs @ 10 mins average, then that’s two days of your testing filled up with just writing up reports.

2) Agree on a detailed bug report with your customer. Try if you can to get agreement with the developer. Try and include as much background information as you can. There has been a load written on what constitutes a good bug report, so I won’t repeat it here.

3) Don’t delay; write up the bug report straight away. This is hard when you’re in the middle of some exciting analysis and you really just want to keep testing in the timeframe you agreed on. But trust me; it takes longer to write them up at the end, when you have to review heaps of cryptic phrases in Session Tester or in your notebook. A capture tool may be helpful in recording data, but if you leave reviewing to the end, it will add additional time and effort to the testing

4) Encourage customers to use a defect tracking tool. It saves everyone a lot of headache and heartache. There’s lots of open source defect tracking tools out there. TRAC and Bugzilla are the two most common.