Spread the Testing Love and Give Group Hugs

[article]
Summary:
Lisa Crispin explains the concept of "group hugs," in which the whole team, or a subset of it, joins in for testing. Consider group hugs if you need to explore how your software behaves with concurrent users.

When our team is preparing a major new release, we sometimes organize “group hugs,” in which the whole team, or a subset of it, joins in for testing. Sometimes only testing team members are involved and sometimes the entire product team joins in or something in between; regardless of who joins, the exercise is always useful.

Concurrency Group Hug: Testers Only
Our newest set of features are about real-time updates, in which one person can see the updates as another types them. With a new feature to automatically save some changes, testing concurrent changes was a must. We’d tested quite a lot individually and our team has been “dog fooding” the feature in production (it’s not turned on for anyone else). Only we testers were involved in this group hug, time-boxed to an hour.

We prepared some test charters and scenarios in advance (mostly, I must confess, by my teammates). These usually started with a persona, doing something our users really do. For example, we envision designers working on a new feature, each adding two file attachments at the same time. Or we envision team members in an iteration-planning meeting, simultaneously updating a story description. The scenarios also captured worst-case situations: I am editing a story while someone else deletes it.

We each chose a different browser and started self-organizing. Sometimes all three of us coordinated to act out a scenario and sometimes a pair did one while the third person pursued an interesting avenue. There was plenty of room for creativity. I was using two machines with two different users to add to the concurrency angle. We tested using shortcut keys as well as other “unexpected” things.

We typed notes on the bugs we found and other observations in a shared Google document. Seeing a bug that one person found often inspired me to think up another test to try. Some bugs we found weren’t related to the theme we were testing, but hey, it’s always a nice bonus.

Here’s a sampling of issues that would be harder to find if you were to test individually:

  • Changing an epic label when someone else has the epic open, the other user sees the new user, but the user who changes sees an error and the label blanks.
  • Starting or moving a story with someone else updating the description causes overwriting and a disappearing history.

One interesting discovery was that we couldn’t reliably reproduce some problems, which pointed to timing issues. This was an area for us to explore more later to see if there was an issue with how the feature was implemented or if we just needed better ways to test.

The group hug confirmed our suspicions that the feature wasn’t ready for prime time. We found several significant bugs and had feedback about design, such as when certain buttons should appear or change color. Our team needed to do some redesign, coding changes, and more exploring before we could consider releasing the feature for beta test.

During the group hug, we realized we still had questions about the desired behavior of the autosave feature. This led to further discussions within the whole team. Within a few days, design improvements and development stories were underway. We’ll plan another group hug, maybe involving more of the team, when those are complete.

User Comments

4 comments
Matthew Heusser's picture
Matthew Heusser

Thanks, Lisa. Personally, I've used this kind of technique when we had a problem that needed simultaneous users (say when a website first went up) - but not as a disciplined part of every iteration, or 'standard process'. It makes me wonder what other people do?

September 25, 2013 - 9:08am
Timothy Western's picture
Timothy Western

I think there's a lot of merit to these sorts of 'bug bashes' as I have heard them called in the past. Sometimes interesting things happen when a system is subject to more than the typical load through a feature. It may not even be an artifact of a performance defect so much as an as to yet unrecognized attribute of the framework it is built upon.

September 25, 2013 - 9:46am
Isaac Howard's picture
Isaac Howard

We often do these types of things. However, if I called them group hugs...the practice would be ended immediately :) These often find lots of bugs the testers didn't think to look for or notice, and allows the testers to also watch other pieces of the company test. We encourage anyone to join us, dev, ops, marketing, sales, customer service etc.

September 25, 2013 - 10:35am
Abby Buell's picture
Abby Buell

I have to keep this in mind. It might not be helpful for a lot of our releases, but in a few cases it could be very useful.

I agree, calling it a "group hug" might not fly here :) What's a really manly term we could call it??

September 26, 2013 - 4:00pm

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03