Cycle Time and Touch Time In Software Testing

It’s been a few years since Bernie Berger published his article “A Day in the life of a Software Tester” (a free registration is required), and the story it tells is close to what many testers deal with today. In theory, Bernie’s job is to do software testing. In practice, he waits until 11:00AM for a build, then there is a problem, which he fixes with a database update — it doesn’t work, so he gets a programmer, who is busy, to look into it. After some time the developer points out the database is out of date, and runs the updates, including the latest one, which Bernie ran previously, so now the data is corrupt. So he gets a database update, which finished at 4:40.

In between every sentence above, you can mentally add the sentence “so he waits”, because that is what Bernie is spending most of his time doing. He does try to be productive, interviewing developers on what the feature should do, learning about the database, and figuring out what he can do on his own. Still, most of Bernie’s time is spent waiting.

If you can’t connect with that story, or if it seems bizarre to you because your organization has on-demand builds that work as expected the first time, with no waiting for decisions and no external blocking conditions, that’s wonderful.

Sadly, that position is rare in software testing.

Here’s how to improve it.

Touch Time

Imagine that a story, requirement, feature, or build is ready to test. Right now. The tester reads the card, goes to the test environment, and begins testing. At the exact same time, the tester starts two stopwatches.

• The first one runs for the entire time the work is in test, to include waiting for bug fixes and builds.
• The second one only runs when a tester is actively working on the story — so it does not include bug fixes, builds, or wait time, because the programmer too busy working on something else to fix it.

If the tester is working on a single feature, and the feature only has a few bugs that are fixed quickly, then touch time could be high (in the seventy-percent range). Realistically, if there are bugs, and the tester is working on something else while they wait for fixes, and need to finish the second thing even after the build is ready, than touch time will be much lower (more like thirty or forty percent).

Obviously, low touch time means there is opportunity to get stories through test much more quickly.

Cycle Time

The second aspect to measure is cycle time — the average time it takes for a piece of work to move from entering software testing. If the test is deeply integrated in development, it might make more sense to measure the cycle time of the whole delivery team — from accepting the requirements, to deployed, to a staging server, or even in production. Today we’ll just cover the test process. If touch time is 30% and cycle time is three weeks, that means it should be possible to finish a piece of work in less than a week — everything else is a delay in the system.

Of course the team will have mandatory meetings, emergency bugs fixes will pop up, and no programmer is perfect. A goal of 100% touch time is unrealistic. Of the many teams I have worked with over the years, however, most could see cycle time reductions of up to 50% by restructuring the work, and all of them had an easy 10–15% win.

Multitasking

Many organizations see “wait time” and they try to fill it up with something. If task A is blocked, pick up task B. If task B is also blocked, pick up task C. This is the quick, and easy way. It avoids conflicts, and creates the illusion of progress.

Notice that word illusion.

Because that is exactly what it is. With Cycle time as a tool, we understand this: Work on three things that are roughly the same at one time, and cycle time will triple at best. That ignores any switching cost between activities or re-learning cost. The reality is, when task A becomes unblocked, you won’t be able to work on it, because you are busy finishing task B.

Once we have the “waits” identified, we can calculate how much “waiting” is injected into the system, and the potential benefit for eliminating it. Realistically, the easy benefit will be from cutting it in half. To improve performance, figure out what is causing the waits, and reduce or eliminate it.

In Bernie’s case, simple practices by database versioning, version control, a daily standup meeting, and a whole-team focus on delivering software over “getting the story to QA” could have had the feature actually ready to test as early as 8:00AM when Bernie came in, if not the night before.

So measure touch time and cycle time. Find where the waiting is. Don’t paper it over with other tasks. Instead, work to reduce the wait states. Do those things, and your test case counts, or sessions per day, stories or requirements tested per week, will all take care of themselves.

The State of Test First Methodologies 2016– Hundreds gave their thoughts and the results are in. Download your free copy.