Category Archives: Uncategorized

Please don’t equate Tragile with Agile

Lajos Moczar recently posted an article in CIO magazine titled “Why agile isn’t working” in which he states that “I’ve concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT”.  He goes on to identify ways in which he says agile is not only failing but making things worse for the IT industry as a whole.

I’ve read the article carefully and tried hard keep a balanced perspective as I perused it.  I can’t keep calm – this article is dangerous unadulterated drivel! The author misinterprets the agile manifesto and takes some of the agile practices completely out of context, using unfounded statements to justify his conclusions.

This post is my response, addressing the points he makes and tackling the myths he propagates.

Leave a comment

Posted by on June 14, 2013 in Uncategorized


STANZ speaker profile: Karen Johnson

If you’re interested in testing you’ll want to hear what testing experts have to say on the subject. At this year’s STANZ (Software Testing Australia New Zealand conference) there will be presentations from four international testing experts. Each week we’ll tell you a little bit more about each of them. This week we’re introducing Karen Johnson.

About Karen:

Karen is a software test consultant. She is based in Chicago but travels to speak at conferences around the world and work with organisations planning test strategy.

She has worked as a software tester or test manager since 1992 after catching the testing bug (pardon the pun) while writing technical guides.

Karen’s testing history is very varied. She has worked with banking, manufacturing and ecommerce software as well as content management systems, medical software and business intelligence initiatives.

As well as teaching and testing Karen is a contributing author to the book Beautiful Testing released by O’Reilly publishers. She has published numerous articles and blog posts about her experiences with software testing.

Working with Remote and Distributed Teams

The biggest key to a successful project is good communication. Unless you always work on your own there will come a time when you have to explain something to someone. Still, that’s pretty easy isn’t it? You just talk.

Unfortunately it isn’t that simple, maybe the person you need to talk to is in a different office, in another country, and is awake when you’re asleep and asleep when you’re awake. Maybe they speak with a different accent to you, or have a different understanding of what certain words mean, or a different cultural perspective. Maybe you’ve never met them, nor will you ever meet them, so you don’t know whether to be very formal or more chatty. Maybe you’ve never worked with them ever before.

Good communication is about more than you communicating out, it’s about considering how your communication will be received by the person on the other side. This keynote talk will focus on good communication skills, how to get them and how to use them when you can’t see the person you’re communicating with.

The Strategy Part of a Test Strategy

Strategic planning is an indispensable skill for test leads and testers alike. A test strategy is the first thing a test manager or lead needs to develop, before you can even write a test plan.

You might not always have all of the resources you would like on a project, so this workshop will show you how to use what you have to get what you need. It will look at ways to get input from other team members. It will help you to get buy-in from all of the concerned parties and overcome political obstacles. Finally it will help you to continuously assess and monitor you testing efforts as your project progresses. After attending this workshop you’ll be able to think and plan strategically on any project that comes your way.

Here is a brief video clip of Karen at the Software Test Professionals Conference earlier this year:

Leave a comment

Posted by on August 15, 2011 in Uncategorized


How to convince your boss you need to go to STANZ

As someone interested in testing, you probably already know about the premier testing conference in Australasia, STANZ. You might even have been before and had a great time listening to inspirational speakers and chatting to other testers. If you would like to go to this year’s STANZ there’s probably only one way that will happen, and that’s if your kind, hardworking boss understands the value of you keeping up to date with the latest developments in testing and buys you a ticket.

If you think your boss might need to know more before that, copy and paste the letter below and send it to them. It explains exactly why STANZ is the event of the year which you should attend. Plus it’s always nice to get a letter.

<Your boss’ name and address>

Dear Boss,

Let’s make your job easier

You seem pretty busy to me. I bet it would be great to have a couple of days to get down to work while all your testers are out at a top quality testing conference. What’s even better is that we would come back with new ideas, practical tools we could apply to our work and buzzing with excitement from having spent time with other testers.

If you’ve spent the last 20 seconds nodding your head while reading this letter then you should book me a place at STANZ, Software Testing Australia New Zealand, or in the other words, the premier testing conference in Australasia.

STANZ is run by Software Education who provide expert training in all areas of software development. They book international experts and local speakers who are independent so they won’t try and sell me stuff. Instead they’ll discuss the important issues facing testers. The calibre of the speakers makes this conference excellent value for money.

All you have to do is go to and book my place to attend. It means I’ll be out of the office for a couple of days but I’ll be back before you have the chance to miss me and I’ll be so proud that you thought enough of me and my career to send me to this great event that I’ll even make you coffee for the rest of the week.

Kind regards,


p.s. if five of us go one of us will get a free place

Leave a comment

Posted by on July 21, 2011 in Uncategorized


New Board Member – Paul Reid

We are absolutely delighted to announce that Paul Reid is joining the Software Education board. Paul is currently the Group Manager, Technology and Innovation at NZ Post, as well as a director of Maven. Prior to this he was CEO of the NZ Meteorological Service and prior to that he held a senior management role at Air New Zealand. He joins current board members Martyn Jones, Brian Steele and John Matchett and with his vast experience including building business in the Middle East and Europe we’re positive he is a great addition to the team!


Tags: , , , , , , , , ,

Do you believe in magic?

Recently, I had the good fortune of seeing Sonny Rollins in concert. Any one member of Sonny’s band would hold the stage on their own.

Sonny Rollins was the drawcard but the concert was not just about him; the band collectively made it about the music, together as a whole, not any one individual. Obvious solos abound but mini-solos and subtle by-lines ran through the various cuts and all throughout you could see musicians seeing, feeling, expressing in response to the others. Two hours flew by like it was only 20 minutes – no breaks, very little jabber, just pure enjoyment.
Watching them reminded me how we strive to bring together our various operational and project teams.

At this point, you’re probably thinking, “Huh? I thought you were talking about Sonny Rollins? What does Jazz have to do with teams?”

Watch a good jazz band and you’ll see a team collaborating and sharing the whole. Watch a tight, outstanding, mind-blowing group and you’ll see magic happening and the outcome is on a whole different level.

How do some groups achieve magic? Watch and learn from the greats… you’ll see they LISTEN to each other and their whole blend. The spotlight is SHARED and they aren’t afraid to TRY. Innovation is part of their nature; dare I say habitual. They display emergent behaviour – complex patterns arising from simple interactions.

Jazz is characterised by improvisation, syncopation tied together by regular underlying rhythm(s). As the team lead or manager, we do whatever is needed to help maintain the underlying directional beat while the overall team contributes their various melodies, counter-melodies and rhythms. We don’t insist on keeping the spotlight or insist on being the only one driving the beat, but work alongside those that we lead. And like a jazz group, a well performing team adapts as the situation morphs and different voices emerge.

Magic doesn’t happen often enough and never happens on its own but the magic is there.

I believe in magic.

Leave a comment

Posted by on June 16, 2011 in Culture, Uncategorized


Tags: , , , , , ,

How technology changes our behavior

I’m a technology aficionado – the latest device, the newest toy, the cool new technologies appeal to me. I subscribe to technology magazines and enewsletters so I know what’s coming next, and am happy to debate the virtues of HDMI over WiMax, Blueray over Bluetooth and why 3G is just too slow! I don’t have to own every new gadget (just most of them), but I make sure I know about them.

Despite this I have always treated computing technology as just a tool – I describe a computer as “just a really fast pencil” and that’s how I’ve lived. Yes, we have four computers and two printers at home (one of the computers is a server), and I’ve had an email address since 1983 (unfortunately not the same one all that time), but the technology has not substantively changed how I run my life.

That changed in August last year when I got a Tablet device (an iPad) – insidiously this book-sized tool has significantly changed my behavior. I purchased it mainly to be a book reader – I’m a avid reader and travel a lot. On a recent trip to the USA I came home with 10kg of new books, and decided that maybe an ebook reader would be a good way to go. I researched the available devices, and decided that the iPad would probably suit me best as it opens up additional possibilities beyond just reading.

I had no idea just how much of a paradigm shift this device actually is. Yes, it’s a pretty good book reader, and you’re not limited in the format of what you read – I have five different reader apps on the device, and can read pretty much any format available today. At last count I had just over 150 books in my mobile library – saves a fortune in excess baggage charges :-). But the book reader has become only one of the uses for the device, and not the driver of change.

What has driven the change in the way I work is the ubiquitous phrase “there’s an app for that” – think of something you are interested in, or want to do, and there’s bound to be an app available to help you do it. Want to convert feet-per-second to Kmh – I use PC-Calc Lite (a fully fledged scientific calculator with over 30 conversions built in). Want to write a WordPress blog entry while traveling at 30000ft, use the WordPress app; want to know the current time in New York, or Bangalore – I use Worldclockr. Want to read today’s newspaper – The NZ Herald app let’s me download the news when I’m in a WiFi zone, and read it later (some of the other news apps use a live Internet feed, I like the offline capability of the Herald). Want to watch a Ted Talk – yep, there’s an app for that too, and this one let’s you download talks for viewing later (a really great way to get value from those endless hours spend in airplanes and airport lounges).

The beauty of these apps is the price – they range from free (most of those I mentioned above) to a few dollars. I think the most expensive apps I’ve purchased are Apple’s Pages and Keynote – and they were less than $20 each. At these prices you don’t bother with “try before buy” – just buy it and see if it does what you want. If it doesn’t do what you’re looking for the write-off is trivial.

This is the secret to the change in behavior – finally the promise of ubiquitous mobile computing is becoming a reality, and it’s affordable. I can check my email in an instant, no waiting for a boot up process. If I want to find directions to somewhere I tap on the Maps icon, type in the address and a comforting blue line shows me where to go, and estimates (pretty accurately) how long it’ll take to get there. If I want to chat with a friend in Israel, or a coworker in Dallas I load Skype and we can talk for hours (almost) for free. Yes, I can do these things on my laptop, but the instant on nature of the tablet means I can do so at a moment’s notice, and the lightweight form factor means I carry it with me without bother, there’s no need to stop and think, I just pick up the pad and am immediately productive, or entertained wherever I happen to be.

The tablet also has some capabilities that the laptop lacks – a built in gps and accelerometer tell me where I am, what direction I’m going in and (one of the best apps I’ve found) Star Walk let’s me hold the device up to the sky and shows me the names and descriptions of the constellations that are visible right now. Yes – I’m a geek, but you’ve got to admit that’s cool.

I remember the first “mobile” computer I worked with – the Osborne One Sewing Machine (they didn’t call it that, but those of us that lugged them around sure did) – I think it weighed 19kg, needed mains power, had 256KB of RAM, a tiny orange & black screen, a keyboard that folded down in the front and dual 5 1/4 floppy disk drives. And it was a steal at a mere $12000! Despite the weight (it was more “lugable” than portable) the freedom to take work to the customer site was liberating. Since the 1980s we’ve gone from lugables to laptops to netbooks and they have all been improvements, but the shift to the tablet factor, accompanied by the availability of a vast range of apps at affordable prices has really triggered a change for me.

I still use my laptop, mainly for work stuff, for bulk storage (150GB of photographs, backed up in 3 places), for presentation delivery and for writing long documents, but I’m finding more and more that I can use the tablet most of the time.

The tablet isn’t perfect, and I’m sure there will be significant improvements over the next few years. Mine hasn’t got a camera (almost reason enough for me to shell out for an iPad 2), and “battery anxiety” is a term I’ve become familiar with, if the battery level drops below 30% I start to get nervous, but I do get a solid 10 hours out of a full charge, plenty enough for a trans-Tasman flight; a USB port would be a good thing, so I can access external storage (those photographs on a portable hard drive). The competing operating systems mean that once you’ve chosen a device you are locked into that manufacturer’s offerings as the apps aren’t compatible between them.

We’re starting to see the low-price app model migrate to other form factors as well, and I wonder what impact this trend will have on the software development industry?

Music companies are having to adapt their business models to cope with digital distribution, and losing control over how their customers consume their music, are software companies facing the same challenge?

Are we going back to the days of the individual software craftsman building a product for a small audience that exactly meets their need, or will software development remain a teamwork activity. Will the software industry split into those building apps and products for the corporate environment using teams of people (probably using Agile techniques) and the solitary developer building a couple of apps, hoping that one will become the next Angry Birds? You can be sure large software organizations are looking at the app marketplace and drooling, will their business models cope with selling an app for $2.99, where they have been used to charging $2999.00?

What do you think, will tablet computing be a new paradigm or is it just the next small step in the evolution in computing?

“Live long and prosper” the tricorder is almost here!

1 Comment

Posted by on May 13, 2011 in Uncategorized


Tags: , , , ,

2010 in review

The stats helper monkeys at mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 2,200 times in 2010. That’s about 5 full 747s.

In 2010, there were 27 new posts, growing the total archive of this blog to 72 posts. There were 16 pictures uploaded, taking up a total of 8mb. That’s about a picture per month.

The busiest day of the year was December 23rd with 76 views. The most popular post that day was Getting Real Customers to Submit Proposals for Agile 2011.

Where did they come from?

The top referring sites in 2010 were,,,, and

Some visitors came searching, mostly for agile test strategy template, social contract example, what makes a good story, software education trainers blog, and shane hastie.

Attractions in 2010

These are the posts and pages that got the most views in 2010.


Getting Real Customers to Submit Proposals for Agile 2011 December 2010
1 comment


Top 10 Exam Tips January 2010


What makes a “good” story August 2010


Agile testing strategies October 2009


What actually happens on an Agile Project – part 1 April 2010

Leave a comment

Posted by on January 2, 2011 in Uncategorized


Requirements Engineering versus Agile

I finally attended this yearly global and prestigious RE’10 event where academics and industry got together to listen and exchange ideas. Much to my surprise, their was a large disconnect between academia’s ideas of requirements engineering with much talk about automation that requires careful consideration of algorithms and language using patterns thought to be more concise delivering a complete and consistent set of requirements.

Many concepts were covered from a different angle – it felt like trying to saddle the horse backwards without success!

Industry people were naturally drawn to the more practical sessions and I genuinely perceived a sense of boredom, “done that and what’s new” kind of attitude where industry constraints such as lack of time and culture were not taken into account.

Much to my surprise there was great hesitance to make mention of Agile – that is, agile techniques were solemnly covered and speakers openly making a point that Agile methodology is merely a farce. I could not agree more in that following a step-by-step approach to implementing Agile techniques is very similar to traditional iterative/ incremental methods but, what I felt was really needed is us all coming together and sharing ideas to mutually build up a tool box full of tools and techniques for agile practices across industries. As long as the RE just keeps attending the RE conferences, the BA just attending BA World and Agilists just attending Agile conferences, we will keep re-inventing the wheel missing out on each other’s complex knowledge that one has accumulated over many years.

Myself included, I am suffering a great deal of being judged as “waterfall” coming from a complex, safety critical environment. I have only worked on one project that was fairly waterfall and it was iterative. The remaining experience was all around RUP (or some version of RUP) thus I am very familiar with agile practises alas; I haven’t worked on pure SCRUM or XP (well, as if one ever implements a pure approach!!!).

Some great games and a great topic on “invention of requirements without speaking to the user” (initially that is anyway) I found stimulating. However, I got most of my ideas by listening to some repetitive old stuff with people completely oblivious to the changes that take place around them.

There were few Business Analysts attending this conference, which makes me think that the rift between the generalist Business Analyst and the specialist Requirements Engineer who will probably remain working in the larger, complex environments such as Transport or Energy will not close. There is even talk about REBOK – as there is talk about some more formal Agile certification!

What we are doing is segregating ourselves – we suffer from immense Role displacement and as long as we cannot find ways of collaborating – we will never find a true synergy of industry practices and we will never ever be truly agile!

Written by Anja Wever, Software Education

Leave a comment

Posted by on October 19, 2010 in Uncategorized


What to look for in system testing

Previous readers of this blog will have noticed the intellectual firepower and sheer passion of the contributors who share their views on testing.

They will also have noticed the blatant and shameful lack of authority with which one contributor (me) replies to questions and issues around testing.

What you may not be aware of is that I frequently also share my confident but dangerously simplistic views on testing when running courses, talking in the pub and anywhere else.  So hopefully those better educated in the mysterious ways of the tester will continue to correct my wayward advice before anyone follows it.

So, with that opportunity, here is an email request I recently received:

Dear TWG (Testing-wannabe-guru):

On our last day of our BA course, you mentioned several things a tester should test for in system testing.  Would you be able to send me the list?

Yours – BA who believes in quality

So here is my response- subject to correction from the pros:

Dear BA

In system testing we should test for things that might be wrong with the system.  You would think this means the process, the IT applications, the training material and other things that a business person would think are the “system” we are delivering.  But this would be hard and might result in a lot of work when we realise there are issues.

So we normally only test the IT applications and even then we only test three  things:

  1. Test things the developer should have already thought of when writing the code.
  • Since the developer should have thought of these things, we should not need to test for them at all.  So you can assure yourself of the system’s integrity by asking the developer “does the system do what we asked you to make it do?”  They will generally say “yes” and look a bit shifty.
  • We then ask the developer “how do you know” and they will respond “I don’t know – its the testers job to tell you if the system does what you asked me to make it do”
  1. Test the developers patience.  You should now ask the developer if they are a proud member of the professional elite of great developers.  They will tend to say “yes”.  Then you say – “Excellent, then clearly you would have not only made the system do what we asked you to make it do .. but even suggested innovative new things that nobody else could have made it do … Surely that is the difference between the adequate developer and the great one.  So, how can I prove to others that you deserve their respect and even their awe?”
  • They will generally look perplexed or annoyed – so ask them “OK, assuming we had great developers then we should only need adequate testers – what would an adequate tester test for to make sure the system works”
  • Now ignore what the developer says, because this is the stuff they  have thought of and that will generally already be working.  This is therefore not what we spend time testing in the system testing phase.
  • Testing the developer’s patience should always be included in your testing.  Not only is it fun, but you will soon learn who the good developers are (they actually do know the system does the obvious things they were asked to make it do) and this is a good measure of the quality of the overall system.
  1. Test for bizarre things the developer would not think  of
  • Begin with scenario tests – create some examples of how people might use the system.  Don’t just look at one requirement but think up and example where the user would want the system to do several things.  For example, to test a banking system, don’t test just whether you can log in.  Do an example where someone logs in, looks at an account balance, performs a transaction and then goes back and looks at the account balance.
  • Think of some more examples (scenarios) and spend about 70% of however much time you have available running these though these examples to see if they work.
  • Now do some “bizarro testing”.  This is often called “exploratory testing“.  Think of random things that someone might do if they were dumb/they were distracted/they were intelligent but did not understand the system/they were older than normal/they were younger than normal/ they were in any way different to how a developer would imagine them to be.  Spend 30% of your time just doing some of these random seeming things and see what errors and unpleasant outcomes you can uncover.

Its pretty easy really.  The only problem is that you will only have a few days available and you will need about 6 months to test the system properly.  So, oddly enough what we pay testers for is not “finding bugs” but

“Spending very limited time to

  • Help the good developers discover the issues and problems they would not have thought of and
  • Let us know if it is likely that the system will suck in production and embarrass the team, or work as designed and make us look good.

I am not sure how they do this with so little time available but apparently this is their job.

Does anyone know how we can do better in system testing that the above approach?  It seems quite straight forward and yet appears to be a real challenge on projects.


Agile retrospectives wiki

Here is an interesting link one of our course participants sent through.

It’s a list of views and ideas centered around retrospectives.  It is not just for agile projects but certainly refers to agile principles and practices.

Let me know what you think.

Leave a comment

Posted by on May 3, 2010 in Uncategorized