Posts Tagged ‘quality’

Agile Testing: A Practical Guide for Testers and Agile Teams

February 3, 2009

Wondering how to get testers engaged in agile development?
Wondering how to transition your QA team from a traditional testing cycle into an agile one?

Then look no further! My good friend and agile testing guru Janet Gregory and Lisa Crispin have just released their latest book:

Agile Testing: A Practical Guide for Testers and Agile Teams

agile-testing

In the book Janet and Lisa cover everything from organizational challenges to tips and tricks on how to get more of your tests automated. It’s a comprehensive overview of everything you will ever need to know about agile testing and a great read for those looking to transition traditional testing teams into more agile ones.

So if you are looking for one book which gives a really good view of a day in the life of an agile tester and valuable role they can play on agile teams, you should definitely check out Janet and Lisa’s new book.

Congrats again Janet and Lisa!

Advertisements

How to host a Bug Hunting Party – Part II

December 11, 2008

Last week, I showed you how to host your own Bug Hunting Party for developers. Well this week we hosted one for business, and while the feedback was completely different, both were valuable tools for improving the quality of our app.

Let me explain why having both outside developers and business trying to break your app is the best of both worlds.

Developers, developers

A lot of people think developers make poor testers. I think that’s rubbish. Some of the best testers I know are ace devs and I would pay cold hard cash to have these guys come and try to break my app. And that’s exactly what we did last week with stellar results.

You see outside developers (those not familiar with the business of your application) have great technical insight into the technology behind how your app is built. They will know what types of exploits you’ll face, what kind of validations you will need to do, and better yet be able to offer suggestions on how to handle any problems they find.

It’s like they are the security guards at the bank with the inside track.

mission-impossible

They also have the added luxury of not really knowing how your app works from the business side. That’s an advantage because they won’t necessary start trudging down the happy path. They will take detours. They will try and do things you never thought of. You can watch them, see where they struggle, and listen for things that are confusing or don’t make sense.

Taking care of business

Business users on the other hand brings an entirely different perspective to testing. They don’t care about technology per se. They care about whether the bloody things works!

As a developer, you can stare at your application for months on end, and not see the forest through the trees. Sit someone from business down however and they can tell you in about 30 secs the 10 things that are wrong with your front page. That’s why we always have business test.

And data. Boy do they know data. When you load up you application with production data, business can tell in an instant if things are working correctly. They have a feel and touch built up that only comes with experience.

You need em both

Of course the ultimate scenario for bug hunting is when you get both parties (developers and business) trying to break your app. Most teams focus on the business (which is the right thing to do) but don’t forget that outside developers can make fine testers too.

So if you’ve done a Bug Hunt with one side of the family tree but not the other, consider inviting both. Developers and business together each bring something different to testing applications, and together form a great one two punch for improving the quality of your application.

Happy hunting!

A special thanks to our hunters

Cameron Young
David Chamberlain
Bill Low
Arthur Tam (hunted)

bughunt2

How to host a Bug Hunting Party

December 1, 2008

Not all agile projects have the benefit of a full time customer, or dedicated QA resource. Yet without their feedback, we still expect our teams to produce bug free, easy to use software. The Bug Hunting party is a fun easy way to get more eyeballs on your application, and give you the feedback you crave. With three easy steps, I am going to show you how to turn a slow, boring Friday afternoon, into one of the greatest feedback sessions your project will ever get.

Not enough feedback

XP and Scrum make it very clear. The success of your project is directly proportional to the input you receive from your customer. Yet many projects can’t/won’t/don’t give development teams full time dedicated resources. The result is that despite the teams’ best efforts, and all our agile software engineering practices, we still somehow manage to find bugs, usability issues and other improvements that somehow evade us during development.

The Bug Hunt

To give your team the extra feedback boost you need to find these low hanging bugs and pieces of usability fruit, consider hosting your own Bug Hunting Party.

Bug hunts are fun, team building exercises, designed to find many of the little hidden bugs, and design usability gems lingering and trapped in your software.
You may not see them. You may even doubt they are there. But when you put your software in front of people, and ask them to use it, you’d be surprised at what they find.

My partner, Arthur Tam, and I just hosted our second bug hunting party this Friday. The results were amazing and there is no reason why you can’t host your own.

Here’s how we did ours.

Step 1. Invite the hunters

Invite as many people as you can. The more the merrier. For us, we pinged all the other developers in our department and dared them to try and bust up our system. The dare is an important part of the hunt. You want people to really try and bust your app, and offer lots of suggestions for improvement. So grease the wheels a bit and throw down a challenge.

the-hunters

Step 2: Host the hunt

Arthur and I like hosting bug hunts on Friday afternoons. It’s down time for most people and they usually don’t seem to have anything better to do anyway.

Snacks are an essential part of any bug hunt. Pop, candy, chips, nuts, a vegetable platter, what ever floats your boat. People are giving up their time to improve your application, so the least you can do is make them feel appreciated by getting some snacks.

snacks

After demo’ing the application, and explaining the business, we go over the prizes. That’s right prizes. We want a bit of a competitive atmosphere and make the hunters know their efforts will be handsomely rewarded with giant chocolate bars.

Here are some of our favorite things to reward for:

  • 1st bug found
  • Most bugs found
  • Deadliest bug found (most severe, the show stopper!)
  • Best UI improvement suggestion

With the formalities over, we then grab our notebooks, and start the timer, and let the hunt begin!

What’s the first thing users do?
Where do they start?
Where do they they struggle?
Do they understand your error messages?
Is your validation right?
Did you forget to strip off empty spaces in all your text boxes?

One of the most important things to remember when conducting your bug hunt is to actively listen and not debate. When a user finds a bug, or offers a suggestion, don’t debate. Just write it down and listen. You’re not there to debate your design. You’re there to improve it, and these people are kindly offering you suggestions. It doesn’t mean you have to act on everything. Just thank them for the feedback and move on.

Step 3: Tally the kills

After 30 – 45 minutes invite everyone back and go over what was found.

Were there any areas of your application lacking?
What was good?
What was bad?
What was the number one improvement each hunter would like to see made to the application?

Give out the rewards and thank people for their time.
And congratulate yourself and your hunters on all the bugs you discovered!

all-the-new-bugs-we-found

Conclusion

Don’t despair if you don’t feel you are getting enough feedback on your application. Create your own. You probably have friends, colleagues, and team mates all around who would love nothing more than to tell you why your kungfu is weak and how your application can be made a whole lot better.

So host your own bug hunt!

If your parties are at all like ours, you will discover a treasure trove of bugs, receive some amazingly insightful feedback, and your application will be a whole lot better for it.

All this, of course, delights customers.

A special thanks to all our big game hunters, and my partner Arthur Tam for use of his camera:

Arthur Tam
Brent Sprecher
Kerry Todyruik
Vu Dang
Brian Low
Umesh Rottoo
David Braat

the team

Quality has nothing to do with testing

June 10, 2008

When people hear the word quality, many of us instantly think of testing.

This shouldn’t be any surprise as the words, quality, testing, quality assurance, QA groups, testers are often lumped together when people discuss quality and software.

What is a surprise for some is how little testing has to do with quality.

Quality on software projects begins way before any tests are written or executed.

Quality begins the first day you start your project.

It begins the moment you engage your customers and figure out how you are going to work together.

It manifests itself every day by the manner in which you collaborate with team members, and the spirit and attitude you bring to the work place.

It’s doing simple things, like getting feedback on you product early and often.

It means managing your project, and setting expectations, so that there is enough time to do the really important stuff, and not worrying about the rest.

It means bringing your A-game every day. Getting knocked down, and then getting back up and coming in for more the next day.

I would do well to remind myself of this the next time I need to deal with a problem of ‘quality’.


AddThis Social Bookmark Button