We could define test velocity as the speed at which we cover the software in order to final risks to quality. If we spend time looking deeply into the software, we go more slowly, but we have more depth. Today’s secret is the secret to test velocity – to go faster than we are going today without sacrificing depth. The video is only five minutes long; details in text after if you don’t to watch.
The secret to test velocity
The secret of test velocity is to actually do it.
That’s it. That’s the secret.
If we actually measured the time people spend testing, it isn’t an eight-hour day. Instead there are meetings, emails, documentation, other projects, describing bugs, arguing if something is a bug, arguing if it should be fixed, waiting for builds, and, sadly, procrastinating. If testing is viewed as boring and no-fun, then the person might slough off the work. No one will really know unless there is a problem, found later. If a problem is found later that person is unlikely to be tracked down. If they are tracked down, they may have left the team (or company). This is a positive incentive for poor work (you get to slough off) and a negative incentive for good work, because you have to do the testing work, which is viewed as a boring low-status activity. Future episodes will talk about changing that perception, but today, it is a reality, which leads to very little time spent testing, which leads to low test velocity.
All that above assumes the person is a “tester” and views “testing” as the primary function of their work. Today, it is much less likely that we see testers, and instead see people from other disciplines doing testing part-time. If you thought it was bad when people whose job is testing don’t do their work, imagine when it is viewed as a part-time, in-your-spare-time activity in the first place.
The second secret of testing is the secret of test velocity. That is is to actually get high test velocity, you have to spend a lot of time actually doing it.
The first way to do that is to hack the brain to make testing a reward activity, instead of something to be avoided. Another way to is re-arrange the structure of the software and team to encourage testing instead of discouraging it. That is what this series is designed to help do – to blow the dust and dirt and cobwebs off the process and look at it with fresh eyes.
More to come.
