If your team already does some pair testing, take a look at promiscuous pairing.

"Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels — and allow someone else to take over for his weaknesses."

Try 60 to 90 minute sessions where you alternate partners each session.

At last night's IWST on time management, Chris Wingate shared a technique he uses when trying to coordinate performance testing for projects. Chris schedules two 30 minute meetings each week. Instead of constantly following up with people to see where they are and to see if he has everything he needs to proceed, he focuses on his part of the project and lets the project manager get and manage other people's commitments. This allows him to work several projects at the same time, because in each of them he's focusing only on his piece of the work and not trying to duplicate the effort of the PM.

For the last year or so I've been using a simple status dashboard to coordinate testing for releases. I find an easy way to share the dashboard is to use a spreadsheet Google doc. Using a Google doc makes it easy for everyone to make updates and see updates as they happen.

Here are the columns I'm currently tracking:

• Client


• Release Number


• Code Complete Date


• First Pass Test Complete Date


• CM Review Date


• Regression Test Complete Date


• UAT Date


• Production Date


• Development Status


• Test Status


• Testing Lead


• Deployment Ticket Number


• Scope Summary

It looks like a lot, but it all fits on one screen (no scrolling needed) and each row in the spreadsheet represents a separate release. If a date is in the past, the cell is colored red. If it's today, it's colored yellow. And if it's done, it's colored green. With one quick glance, you get a high-level view of all the releases and their current statuses.

Many teams track release status by tracking the status of tickets in the release. A ticket might be a story, feature, or some other unit used to tie work to a release number. That is, if a release has 10 tickets in it (regardless of if those tickets are bugs, features, or other), the release isn't done until those 10 tickets are done. For most teams, testing is part of the ticket workflow.

When you're working in this type of environment, you often do your test planning for the release upfront. You might charter testing for certain tickets together or break up testing across multiple testers by assigning testers specific tickets. When you do this, you always run the risk of someone adding another ticket into the mix before you've finished your testing. While most teams (hopefully) have some communication methods for this type of change, sometimes tickets sneak in.

Whenever I'm testing a release like this, the last thing I do before I call my testing "done" is to go back and make sure no new tickets were added. Most tools make this very easy to do. All I'm trying to do is reconcile my testing efforts with the release before I hand it off to the next stage. Occasionally, I catch something that got slipped in that my testing missed.

Catherine Powell had a great post yesterday on calculating velocity. From that post:

"So now we know that each QA engineer can do about 2.5 units of estimated work each week. When we go into the next estimation session, that's where we'll draw the line for test work. We estimate just like we always do, and we then will walk down the list committing to 2.5 units of work per week. When we run out of allotted time, we'll stop."

There are a couple of great tips in that post, and the overall focus on developing a method to calculate velocity if well done.