Before adding more work, ask what people are working on
I was recently handed the "gift" of a very aggressive deadline. It happens, you don't set the date - it gets set for you. (Ironically, Johanna Rothman just wrote a short bit on that topic on her blog.)
When aggressive deadlines get set for you, if you're like most managers, you start to ask questions to see how realistic the dates are and you try figure out what exactly you can and can't get done in that time frame. When I do that, I ask my team to help. I often pull people in early, and ask them to start looking into what testing we need to do, what environments we'll need, what data, what... you get the idea.
An important question I ask before I start to pile on more work (because any time I ask a question, I'm likely asking for more work), is what they are currently working on. Sometimes I'm surprised by the answer. I have a fairly self-organizing team, and they juggle a lot between themselves without checking with me first. So by asking first, I can keep myself from becoming my own biggest problem.
Before adding more work, ask what people are working on. Then, if they have too much, work with them to prioritize what needs to be done first, and what can fall off their plate.
MARTA for managing risk
In a recent blog post, Antony Marcano posted his mnemonic for managing risk: MARTA
Mitigate
Avoid
Reduce
Transfer
Accept
Read the full post for details behind each point.
Instead of focusing on best practices, focus on…
Susan Cramm recently wrote an article on best practices on the HBR website. In the article, she points out that:
In reality, "best practice"...
...isn't always the "best"
...often isn't feasible
...is sometimes unachievable
Instead she recommends focusing on...
Adapting best practices...
Defining quality processes...
Having experienced people...
Checkout the full article for details.
Capture charter velocity
When I'm managing session-based exploratory testing, I spend a lot of time measuring charter velocity. There are a couple of key dynamics I look at:
- charters executed per day
- new charters created per day (broken down by charter priority level)
I typically capture these by tester, but I often look at them as a team aggregate. While I'm interested in individual trends for coaching, for a team of more than two testers, it's more interesting from a team perspective when it comes to creating trendlines. I show an example of how I use these numbers in a recent SSQ article.
Thumb vote for priority
Sometimes, when reviewing charters with the team, I look to them to help provide some insight into what we should be focused on with our testing. One technique is to walk your list of charters (all twenty or them, or all 200) and have each person provide some insight into where they think it falls in priority. To facilitate this, I sometimes use a thumb vote.
When thumb voting, everyone must vote. There is no sideline. Since I usually use three levels of charter priority (A, B, and C), those map as follows:
- thumb up = A
- thumb sideways = B
- thumb down = C
What I find is that for most charters, most people on the team are on the same page (or really close). Every now and then, you have to make a decision on a close tie (but since you're the test lead, you're use to doing that anyway). Sometimes however, you see some odd votes. Like four up and four down. Those votes normally lead to some really great conversations. Often, people misunderstand the charter or have a different understanding of the risk involved. This surfaces those differences.
It's also fun. (In an I'm-a-tester-so-voting-on-charters-is-fun sort of way.)
Let the PM manage getting commitments for you
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.
Simple status dashboard
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.
Before you consider yourself “done” testing, go back and double check
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.
Calculating velocity
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.
