Project Practitioners > Avoid Testing Whack-A-Mole

Avoid Testing Whack-A-Mole

By Kent McDonald

I recently completed a project where we were implementing a new customer facing application on which we needed to test several configurations. We were testing in a test environment, that unfortunately like most test environments was not a direct representation of the production environment. That constraint not withstanding, we launched into testing and quickly began running into issues. We would find one issue, get it logged and report it to the development team when another issue would pop up, then another, and another. It soon began to resemble the carnival game whack-a-mole where you hit one mole and three more would pop up.

Because the development team was distributed, but in relatively close time zones, the issue whack-a-mole quickly degenerated into an email whack-a-mole where an email reporting an issue was followed up by questions from the development team followed by responses by the tester, and sometimes comments from those copied in on the email chain that really did not serve to aid anything.

We quickly realized that we officially wrapped ourselves around several axles. We called an all team meeting and quickly agreed to a couple of simple, but very effective things. First, even though we were under a very tight time frame, we decided to suspend testing until some key configuration issues were resolved. Second, we changed our mode of communication. We took steps to avoid sending multiple communications about a test issue to the development team, we started short daily conference calls to discuss testing status (yes, we should have done that from the start), and finally, we implemented the rule of three (as suggested in an IIBA Quick Tip) which states that once you are on your third email about a subject, it's probably better to pick up the phone and call the other people on the email chain.

Luckily, we only played Whack – A – Mole for about a day, and although we lost two testing days while the configuration issues were solved, we no doubt saved countless hours that otherwise would have been wasted.

Related Links
If you find yourself needing frequent communication, try daily hot-list meetings or Agile stand-up meetings to keep everyone on the same page. Formal environments may benefit from a software bug fix WBS to reduce confusion.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Good post, and good ideas! Is your team using an issue tracking system while testing? Those can be incredibly valuable! Once I started using those I just couldn't go back, the thought of sending bug details via email just seemed too inefficient.

Hi Dina, thanks for your comment. You bet we have an issue tracking system. Remember how I said the team was distributed, not only are they geographically distributed, they are also organizationally distributed, meaning they are a vendor. Based on the way my organization set up the test tracking system, we were unable to provide access to these external folks. Not ideal, I realize, but this project was small enough we had to be creative to get around our self inflicted obstacles, hence the emails.

I'm very happy to hear that the email RoT rule has helped you out. Have you continued to use the rule since then on other projects and in general?

I have and continue to try to use that rule for all project communications, however seeing a name given to it was just a good reminder.

Notice I said try, unfortunately Yoda was right when he said "there is no try..." Things like this require frequent reminding.

Regarding your comment "we were unable to provide access to these external folks". Have you considered using one of the many online project collaboration sites? I have similar problems with sharing information with customers and external contractors so use online collaboration. Can be a bit of an overhead for managing some info but saves on the email and gives instant access to everyone in team.

Hi Roger, Thanks for your comment. An online project collaboration site is certainly a consideration, however my organization is very concerned about securing test data because of it's sensitive nature. Any use of public collaboration tools would entail a great deal of research and due diligence prior to using it, which we did not have time to do for this project, as it had a rather limited scope and budget. I mention that not as an excuse, but to point out that sometimes considerations drive less than ideal process selections.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.