Growing test teams: Progress Martin Jansson
A lot of these ideas come from Peopleware by Tom DeMarco and Timothy Lister. As I see it, they realised it is easier to show things that will stop the growth instead of listing things that will actually create the team. Jelled teams are created when many of the factors have been eliminated that stop us from growing.
What stops growth of a test team? I identify new things almost every day that in one way or another disrupts the team or stops it from growing.
The hunt for test progress!
When we talk about progress it is directly linked to a goal, thus progress towards a certain goal. If the goal is unclear or has been lost, the progress estimation can sometimes shift toward things that was not meant to be.
How do you determine progress then? When are we done testing? If our plan from start is fixed, we might have a defined set of tests that must be run in order to say we are complete. That is, complete with what we thought from the beginning. But the plan changes, no? If that is the case the progress report is ever changing up or down. Is it perhaps not really that interesting to focus our time on bulletproof progress estimations? We stop testing when time runs out or when someone says stop?
I think the test team have a harder time growing when …
- the ability to show test progress becomes more important than the actual testing done or the information produced from it.
- we think it is important getting more green than red in the pie chart or bar chart.
- we avoid testing areas that might result in bugs because that might disrupt the expected weekly progress.
- it is more important doing a test that show progress than doing a test that might actually find bugs.
- we avoid helping developers fix the bugs found because we need to show test progress.
Too much focus on progress will generate bad energy in the test group and therefore slow us down, as I see it.
Some disparate thoughts:
I like this “the opposite” approach; it can also be used for questions like “how could we test the software in the worst possible way?”
What do you mean with a “growing” test team?
Aren’t these issues general for all projects that are somewhat fuzzy or abstract?
Is it a society trend that it is more important what it looks like, than what it actually is?
“Think the opposite” is a powerful tool.
Regarding “growing”, I guess it is the essence of the book. You grow instead of create, by removing obstacles that hinder growth.
Progress is in general a hard thing to measure. There are so many things that could happen no matter what you do or how you plan. Still, in many situations the testers are in focus at the end of the release and their progress becomes a bit too important, as I see it.