Free testing book

Via Ben Kelly, Rikard Edgren’s brief but dense ‘Little Black Book On Test Design‘ is worth a read.

It’s cheap both in dollars (free) and time (less than 15 minutes if you’re quick).

The second MAST meeting, finally

Another year, and a chance to bring enthusiastic testers together to network and learn from each other. To this end, I’m going to be organising public MAST gatherings. This will be a bi-monthly drinks night at a venue to be decided. In addition to this, I’ve set up a Ning group to allow members to chat to each other about local issues and to manage announcements and attendance for the group.

You can register your interest by following this link: http://melbournetesters.ning.com/?xgi=2edcWVP

I also recommend joining the other tester club on Ning at Driven QA – http://club.drivenqa.com and finding the ANZAC group.

Hope to see you all soon, and apologies to the person who emailed me about MAST recently. Thunderbird managed to destroy your email before I could reply. The tester ‘black thumb’ apparently extends to applications that I’m not trying to test as well.

Planning to make use of learning – Incremental vs Iterative

During coffee with Agile-coach and all-round excellent guy Shane Clauson, in sympathy with yet another of my what’s-wrong-with-agile rants, he pointed me to this blog post from Jeff Patton:

Don’t know what I want, but I know how to get it

While my opinions diverge on some of what he says must be true, I think the important message that he (and others – Check Alistair Cockburn’s writing on this) make is that it pays to plan to iterate. That is, if you’re on an agile project and you don’t see anyone planning to rework things in response to feedback from using the product, you’re probably in for some disappointment.

I think we frequently fail to give our customers an appropriate expectation when it comes to (agile) software development. Having them read this isn’t a bad start, but you’ll want to figure out how to make this message your own.

Interview on Dr. Dobb's Journal

I wask kindly asked to answer five question for the Braidy Tester’s Dr. Dobb’s Journal Testing and Debugging page. It was a nice chance to reflect, and you can read my ramblings here:

http://www.ddj.com/blog/debugblog/archives/2007/12/five_questions_41.html

Enjoy!

Personal growth and fertilisers (or fertilizers)

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!

The Egg testing challenge, context and mission

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…

Back to school…

I’m back at university, in an effort to force myself to knuckle down and get through the pain of learning Java. It’s been 16 years since I was last there, and here are a few of the things I’ve learned so far -

I’ve learned about the syllabus
Despite the move to Java, very little has changed in the overall teaching approach in 16 years. I’ve heard from another source that someone in my position 15 years ago may have been saying the same thing.

I’ve learned something about gold-plating
University seems to reward you for adding extra features. This doesn’t seem to happen in the business world.

A couple of years ago, I had a graduate developer assigned to my test team to help extend a test tool that I had written. He seemed overly focused on wanting to build a GUI for my tool, when a simple command-line interface was all that was needed to solve our problem. Similarly, with a user base of three, robust error handling was something we could live without. After a couple of semesters of university assignments, I think I understand why this was the case.

I’ve learned something about testing
Lecturers are mostly not embracing some of the not-so-recent trends. I’ve found JUnit tests a boon on assignments where we are incrementally adding new features. Having these tests as I implement existing functions using newly-learned language features, or to add new functionality for new assignments makes things much less stressful. Implement a test per requirement also helps to make sure I get all the marks for the assignment as well. When I suggested a student learn JUnit rather than passing parameters to their classes manually via a GUI interface, lecturers seemed against it, despite the many practical (and career) benefits.

I’ve learned something about learning
University seems really keen to have students build GUIs on everything. Now, GUI building seems like a reasonably complex thing, object-wise. As a beginner, figuring out how to model the domain is hard enough without being forced to put a hacky user interface on top of it.

Learning to model a domain doesn’t start with modelling the user interface.

I’m sure there are more progressive courses out there. I’m just surprised that the take-up of things that are of much benefit to beginning programmers is coming along so slowly. But then we are always making a tradeoff between what we can easily teach and what’s worth teaching. Just look at tester certification.

Be a Ninja Tester…

James Bach is going to be in Melbourne early June, teaching his Rapid Software Testing course. If you’re in Melbourne, don’t miss out. If you’re not in Melbourne, try to get there anyway!

Details can be found at http://www.softed.com.au/Courses/rst.aspx

Study session difficulties, or the Learning Organisation challenge

In the Yahoo group supporting Cem Kaner’s Black Box Software Testing course, Anil Soni has been describing experiences organising and leading internal training, using the BBST course materials. One point in particular caught my attention:

> The major challenge is to have all the testers together in the same time
> needed for the group interaction.

In a recent role, I had trouble getting all of my testers together for study sessions. Often, the testers felt uncomfortable stopping work to come to a study session. At times, work was a genuine priority. At other times, the things testers were working on could wait an hour or two, but it was difficult for the tester to make that decision.

Sometimes I would have to make the decision for them. That is, tell them “This is more important than the work you are doing right now”. I could do this because I had management support for creating a learning environment.

Organisationally though, we were sending mixed messages. The project manager expressed the opinion “We’re not running a school here”. The development manager countered with “We absolutely are”. These two statements captured the tension between getting today’s job done now, and ensuring that tomorrow’s work can be done better or more efficiently. In one statement, is the view that employees should always be working on something that directly contributes business value. In the other statement, the view that it is vital that time be set aside during work hours expressly for improving the skills of staff and for reflection on past experience.

At this point, I don’t really want to enter into the philosophical debate around whether organisations should be learning organisations are not. However, if you’ve decided that it is important that your staff learn and improve here are a few things that I would consider.

  • Make it clear how much time you expect employees to be spending on improving their skills.
  • Check that they are spending the necessary time. If not, find out why.
  • Keep groups small if possible. This allows scheduling to be more flexible.
  • Get a clear statement (or statements) from whoever is in authority that study time is important for the organisation.
  • Establish and communicate principles for when work should take priority.
  • If participants are having difficulty deciding what is more important, help them.
  • If you are going with a less structured informal learning approach, how will you know whether team members are using their study time for study? That is, what feedback mechanisms will you have to help understand and support your team’s learning needs?

On this last point, in one team, a thousand dollar self-education budget was available to each employee per year. They were free to spend this on anything that they wished. However, in a year and a half, almost none of the team had made use of that budget. That’s one example of a feedback mechanism, triggered by the question “Why haven’t you used your training budget?” Regular team meetings, where each team member presented some recent learning were another.

The dominant work culture is about appearing to be busy, and doing ‘real work’. Despite support at the highest level, if other management levels don’t support the company’s learning objectives, employees will be quite nervous about spending time on tasks that their close managers may consider trivialities. This is a significant cultural change, and the forces of history will be working powerfully against you.

I’ve recently come across the Informal Learning blog, and hope to write more on this subject in the future.

About me

I'm Jared Quinert, a testing consultant located in Melbourne, Australia. With over fifteen years of experience, I specialise in agile testing, context-driven testing and intelligent toolsmithing with a focus on business outcomes over process. As one of the most experienced agile testers in Australia, I've been diving in hands-on since 2003 to discover how to build successful whole-team approaches to software development.

Contact Me