You Want it When?
Doing test planning for my current project phase has been a challenge because we have so many things to complete in a short period of time. I was totally overwhelmed looking at the total number of things we had to test with two people. It seemed impossible for awhile even though I know it is possible to deliver helpful test data in ANY context being from the context driven school of testing. There is one simple thing that was a huge breakthrough and it is totally simple.
We have a testing schedule for the rest of the project. A what? Yes. A simple list of what happens when so I know if we are behind or not. This isn’t for the project. It is just for us. Because if we do things to plan we WILL deliver great testing. A simple weekly schedule for us to follow is the simplest thing in the world. So why? As an agilist what in the living daylights am I thinking?
1. This isn’t an agile project.
2. It isn’t in my control.
3. This isn’t one project. We have about 8 mini-projects to manage instead.
4. A test plan ain’t gonna cover this situation unless it helps us DO the testing.
Break it Down
What buckets of testing do we need to complete? I don’t mean test cases, I mean huge buckets/topics of testing. This is just the headlines.
What is due when?
What can we start?
What do we need first?
When do we have to start what we need first to be finished with that when we can start?
Line it Up
For us, lining up what to start each week helped. Could be different in other situations.
One Day, One Tester, One Deliverable, One Completion at a Time
No longer stressed. If (and this is a BIG if) we get what we need to start on time, I am CONFIDENT we will rock this project on the testing side. This is well within our capability. It can be 20% messy and we’ll still pull it out. Haven’t figured out how to express that risk in the plan other than show days slippage on dependencies. Examples are welcome.