If you’re looking for a course different to the usual fare, you might want to check out Rob Sabourin’s “Just in Time” testing course, which will be running in Sydney on the 12th and 13th of November, and in Melbourne on the 15th and 16th (New Zealand after that). I’ve heard good things about his presentations the last two years at the STANZ conference, and am hoping I may get to the course.

Part of the course materials include session-based testing, so if you can’t wait for Michael Bolton or James Bach to make it out here next year, this is a chance to find out more.

Details of the course are on the Softed website (http://www.softed.com)

‘Capturing the essence’, or ‘core’, has been a key theme in some of my work recently, and in several of the books I’ve been reading. So over a drink with Michael Ruschena tonight a couple of these came out as we linked ‘the core’, ‘agile’, and haiku – poetry that captures the essence. I’ve been coaching a team around testing on agile project, so I thought it might be fun to try to capture the essence of that…

I thus present agile testing haiku.

Note: I’m just going to keep adding new ones to this post so that they’re all in the one spot. And increasingly I’m finding these are not just about agile development, but software development generally.
————————————————–

Method it is not
Apply values, principles
To meet your own needs

Planning game is key
How do we know when we’re done?
Check the product goals.

Can’t make it all fit?
You’ll need to take something out
or get more money.

This user story
Does not express your intent.
Why, why, why, why, why?

Push the risk up front
Shorten the feedback cycles
Highest value first

Development, test
Are all part of the same team.
Try working closely.

Good acceptance tests
Set goals but skip one main thing -
Implementation.

We got a green bar,
Why is the customer sad?
Just add a story.

I didn’t do it.
It wasn’t in the story.
Look, new offshored jobs!

Exploratory tests
Help find problems most quickly
but make extra work.

Skilled software testers
Use many different models
Try many angles

Though up-front tests help
We can get stuck in a rut
Go and have a beer

Embrace fuzziness
Precise is not accurate
Band your estimates

Some we can know now,
but some we must build to learn.
Best tell the owner.

Start with a small team
When the hole size becomes known
let everyone dig

Unit, story tests
Why is our build getting slow?
More techniques will help.

How are we going?
If you can’t tell at a glance
have visible charts

Rough iterations?
Preserving uncertainty
may help things improve

Estimate fully
But to manage greatest risk
Take away two thirds

The test strategy…
What information and how,
tied to the vision

Left values or right?
What’s the pairing’s principle?
You’ll need skill at both.

The grind of agile
Sprinting then taking a break
helps you sustain pace

What is knowable?
Predicting or reacting?
Find your middle ground

The requirements.
Stories are only a third.
What about the rest?

Who’s your customer?
You have no ******* idea?
Find out quick or stop.

I feel very ‘tech’ now. I’ve uploaded an edited audio version of the last MAST meeting, where we (Erik Petersen, Kristan Vingrys and me) attempt to answer John Gallagher’s questions about testing in agile projects.

Find it at http://www.quinert.com/mp3/mast200709a.mp3

Enjoy!

The three beeps protect the innocent. The first is a service provider, the second and third are internal departments of one of John’s past employers.

In response to Matt’s comment on the robustness of my Tiny MCE Watir solution, I’d like to point out that the main threat to the solution’s value for me is that I can no longer run the automation in the background. Send_keys seems to need the IE window to be the topmost window. A lot of my Watir use is for tool-assisted testing rather than complete automation, so being able to leave a script running, go and do other things, then come back when the script has finished is a bit of a problem for me.

Anyway, I’m sure if you are running scripts as part of a build, or have a separate machine that handles all of your test execution, this is going to be fine for you. For me, it’s not quite what I needed. Just remember, quality equals value to some person…

I wonder if Google testers think like this?

http://www.radaronline.com/from-the-magazine/2007/09/google_fiction_evil_dangerous_surveillance_control_1.php

The concept of inattentional blindness has been, if you’ll excuse the unintended pun, brought to the testing world’s attention lately by Cem Kaner and James Bach. Sajjadul Hakim has written recently on an exploratory testing experience in which he attributed failure to observe a bug to inattentional blindness.

While this may have been the cause, it is worth pointing out that our attention is a fragile thing. Inattentional blindness is but one of the ways that our brains can let us down while testing. Here are a few more:

Attentional blinking

If something grabs our attention, then something else happens almost simultaneously, or just after, we may miss it.

Inhibition of return

If something happens somewhere where we were just looking, we are less likely to see it.

Negative priming

Our brain applies filters to suppress things that are not relevant to the task at hand. These filters can arise through conscious effort or can happen if we perform a task long enough. An example of this is ‘banner blindness’, where things appearing in the spots where website advertising usually appears are highly likely to be ignored.

I became acutely aware of this effect last year. Steve Irwin had just died, and the news came to our team via a phone call to a teammate. I immediately jumped on CNN’s website, looking for confirmation. “There’s no news of it here,” I confidently claimed to the rest of the team. I looked back at the screen, and scrolling across the top of the page was a ticker, proclaiming Irwin’s death as ‘Breaking News’. It’s position at the top of the page, where advertisements usually appear, had caused me to skip straight over it.

Our brain is able to put filters in place to help optimise our performance of common tasks. These effects can last for more than a month after we have stopped performing the task that caused the filters to be put in place, just in case we need to do it again.

Our brain’s processing power is limited. In addition to the above problems, sometimes there’s just too much for it do deal with. It has developed tricks to help us survive lapses of attention, but these are also things that can catch us out as testers. The act of operating the product in order to test it is something which focuses our attention. By doing so, we blind ourselves to some problems.

I play video games with a kind of unfocused stare, and I suspect this actually helped me detect different kinds of problems when testing games, while probably making me blind to others. I find I can’t usually test applications with that protracted stare. I can however observe the application this way by putting the application under computer control, or by observing a playback of a recorded session. Video recorders and Watir scripts are great for this, and give you the chance to find different problems. James Bach also frequently recommends Spector for recording testing sessions.

Strategies

There are plenty of strategies for reducing attentional failures. Mix these up over the lifetime of the project for best effect. Some of them I’ve described already, but others I leave for you to Google -

- Rotate people through projects and tasks to avoid negative priming.
- Negative priming effects are reported to be reduced by alcohol consumption. Have a drink at lunchtime. Tell your boss science says it’s OK!
- Pair up…Maybe even with non-testers or people who have nothing to do with the project.
- Use recording tools and go back and review your testing sessions.
- Automate operation of the product, sit back and observe. I’ve used this technique, and Jonathan Kohl has success stories to tell as well.
- Blink testing. This is a defocusing strategy popularized by Michael Bolton and James Bach. Find different problems in test results, fast, by taking the detail out of them and scrolling through them quickly or zooming out.

If you would like to find out more, check out the book Mind Hacks: Tips & Tricks for Using Your Brain (Hacks). It’s a great primer on your brain, how it works, and how it can let you down. The ‘Developing Intelligence’ blog is also another great source of information and ideas.

I’ve spent far too much of the last day and a bit trying to get Watir to identify and manipulate the TinyMCE rich text edit control. Hopefully the title of this post will allow anyone experiencing similar problems to Google my solution!

TinyMCE does a lot of javascript nastiness (from Watir’s perspective), turning a text area HTML tag into a funky iframe WYSIWYG text editor. Watir seems to have trouble doing much with it, but I was finally able to get an acceptable (for now) solution:


#Substitute your TinyMCE editor instance for 'mce_editor_0'. It will probably usually be OK though.

$ie.ie.Document.parentWindow.execScript("tf=document.
getElementById(\"mce_editor_0\");tf.contentWindow.focus()")
$ie.send_keys("Hello there")


It’s not nice, but it sure beats yesterday’s solution:

20.times{$ie.send_keys("{TAB}")}
$ie.send_keys("Hello there")


You would think that this kind of message would be a thing of the past, but apparently not. Or at least not when buying tickets to major exhibitions in Melbourne.

Today, I’m translating the Korean children’s story ‘puppy poo’ for my blog. It turns out that somebody has already translated it, so it’s not the world-first I thought it was going to be. Oh well. I needed the Korean practice anyway. It’s a touching children’s story, about a piece of poo who finds meaning and acceptance fertilising a dandelion.

You can read along with the story and view an animation here:
http://www.doggypoo.co.kr/. The book and movie adaptation can be found on Amazon.

Puppy Poo, by Kwon Jong-saeng. Translated by Jared Quinert.

One cold winter day, a puppy pooed on the side of the road…

A sparrow flew down and began pecking at the poo.

‘Poo! Poo! Geez, you’re dirty!’ said the sparrow.
The poo’s heart was deeply hurt. “I’m dirty?” he asked, to noone in particular.

A clod of dirt nearby began to laugh.
“Why are you laughing?” the poo asked angrily.

“You’re poo, so it’s true. In fact, among all poo, you’re just about the dirtiest”, said the clod. The poo broke into tears.

Along came a farmer with his cow.
“That pile looks fairly fresh”, said the farmer. “That would be great for my vegetable patch”. The poo’s heart rose!

The farmer scooped up the hurtful clod of dirt, leaving the poo alone as the air turned cold. “Seeya, filthy!” shouted the clod as they left.

It became dark, and started to snow.

The snow buried the poo, and he fell into a deep sleep for the winter.
The warm spring came, and the poo woke from his hibernation.

In front of him was a dandelion shoot.
“Who are you?” asked the poo.

“I’m a dandelion. I’m going to bloom into a beautiful star-like flower”
“How are you going to manage that?” asked the poo.
“Well, as long as I get some mulch or compost, I can bloom” whispered the dandelion, with a twinkle in his eye.

“Really?” said the poo, surprised. “I can be mulch or compost!”

The puppy poo happily embraced the dandelion shoot.

Suddenly, the Spring rain came, washing over the poo’s body, breaking him down into fine pieces, entering the earth and fertilising the dandelion.

The day broke, and dazzling sunbeams shone over the dandelion’s bright flower, which had now bloomed. The flower’s scent flew on the Spring breeze.

The poo’s gentle heart had filled the dandelion’s blossom.

———————

Now, the moral of the story is supposed to be about everyone having a purpose. I’m going to offer an alternate moral, based on some recent consulting engagements:

Sometimes, in order to grow, we need to associate with turds. Or be buried up to our neck in poo.

Now, I’m not really sure if that’s one moral or two, but it does describe my reason for trying consultancy in the first place. That is, I needed to be outside my comfort zone in order to grow professionally. There have been lessons, and I’ve enjoyed my year or so of consulting. I’m looking forward to my new role’s balance of internal project work and external consulting, which should be the best of both worlds!

I highly recommend that everyone spend a little time figuring out what fertiliser might be best for their nourishment.

Good luck!

Matt Heusser is describing his challenge to test various inanimate objects – An egg, a stapler, a salt shaker and a knife. Read it here, but be sure to come back for the rest of the problem.

I’d now like you to spend a few minutes thinking about how you might go about testing an egg.

Now I’d like you to read this and this. (Oh, read this if you can’t read Chinese. Oops). Now ask yourself if there’s anything you’d like to change about your egg-testing strategy. Or another question you think might be worth asking before you start testing the egg.

The questions that leap out at me are -

- Who am I testing this for?
- What is the purpose of the egg?

When testing, we often assume the answer to these questions without checking what our mission really is. This can lead to unwelcome surprises at the pointy end of the project.

Now you can read this and start thinking about your egg testing strategy again! Happy testing…