From my previous post 12/24, Mykhailo Poliarush asked about testing task cards. I’ve seen several different approaches to planning testing tasks during iteration planning and managing them throughout the iteration.
One approach is to use stickers on each development task cards. For example, a yellow sticker could denote the task is ready for testing, a green sticker could denote that it has been verified. Or one could simply write testing activities needed for each development task on the back of the card (or in its description, if you’re using an electronic story board such as Mingle).
My team has used this approach successfully for the past five years: When we write task cards for a story, we write testing cards as well as the cards for coding, design meetings, database tasks, infrastructure tasks and so on. When we had a physical story board, we used green index cards for testing cards, and white for other types of tasks. That way the testing cards stood out easily and we could tell if testing activities were getting squeezed towards the end of the sprint. We estimate each testing task card in hours, just as we do the development task cards.
Now that we use Mingle for our story board, we don’t have a way to color code them, so we write “Test” in front of the description of each task, for example:
Test – Write high level test cases for adding a validation for non-active employees
The details about the testing activities go on our team wiki, not in the task card itself. The task card has the estimated hours and the status. Each task starts in the “to do” column. When someone picks up a testing task card, it goes to the “WIP” column and is assigned to that person. When finished, it goes into the “done” column.
I like having separate, easily identifiable testing task cards, because we can tell really quickly if we’re getting into a bind with testing. If a lot of stories have their development cards in “done” but there are still lots of test task cards in “To Do”, and there are only a couple of days left in the iteration, that’s trouble. When we see this trend, the developers stop working on new functionality, and start taking on testing task cards along with the testers.
I’m often asked “How do you know how much time to estimate for a given testing task?” This definitely depends on the application being tested, on the infrastructure available for it (for example, do you have a test schema with useful test data already in it?), the testing expertise of the team, and other factors. You’ll start to notice trends as you go. Testing task estimates for any given story of ours usually adds up to about 50% of the total development task estimates. So if the testing estimate is way above or below 50% of development estimate, we look to see if maybe our development estimates are off, or if it’s just a situation where a story is either very easy to test or highly test-intensive.
Never get too hung up on estimates – they’re just guesses. Even when you’ve been working on the same application for five years, any story can surprise you!
The main points here are:
- Make your testing tasks visible
- Include your testing task estimates in your story estimates
- Everyone on the team should pick up testing tasks when necessary
