Paul Holland, a senior test manager responsible for modem testing at Alcatel-Lucent, had a problem. On the one hand, he had an experienced team of four testers—the newest member had arrived two years earlier with five years of experience elsewhere in the company. Paul himself had a good handle on what needed doing and how it was being done. On the other hand, he had a challenge: to convey his understanding of the team's status to project managers in a way that not only kept them informed but also kept their attention directed toward the most important bugs and project issues.
Paul had tried session-based test management (SBTM) as described by James and Jonathan Bach , using both the ninety- minute timeboxed sessions and lightweight tools to report test coverage. He ran into two obstacles: Since his testers were highly skilled, they were often in demand for special projects and immediate advice from programmers, other testers, and product managers ("high-priority interrupts," as Paul calls them). Phone calls, in-person requests for help, and follow-up emails meant that the testers found it hard to set aside uninterrupted testing time. Paul also found that the coverage data generated from the SBTM sessions was subject to mis- or over-interpretation by stakeholders.
He tried at first to use an Excel spreadsheet as his tracking tool. This might have worked well had Paul been the only person who needed access to it. Since several people needed access to the sheet for reviewing and updating, file locking was a problem. Having opened the sheet, people would inadvertently leave it open (and locked), and upon encountering a locked file, people who were temporarily unable to update the sheet would forget to do it later. As a result, the work and the project tracking got out of sync. For about a year and a half, Paul used a simple file in OneNote to manage charters—mission statements for the testing sessions—and their results. This worked reasonably well within the test team, but something was missing. Paul had to push out both charters and project status to the team, and visibility outside the team was poor.
The company had recently begun to adopt some agile practices, but these were largely focused on the programmers and the product managers. One day, as Paul went past a Scrum meeting, he noticed a whiteboard covered in sticky notes. The whiteboard was the center of an active discussion between programmers and project managers about the project status. After the meeting, the whiteboard and the notes on it remained as a kind of information radiator .
"I suddenly realized that if they could do that, I could too," Paul said. He began by dividing the whiteboard into three columns: To Be Done, Work in Progress, and Done. He used stickies to represent sessions based on half-day units of work, as shown in figure 1. “Half-days are really easy to see on the board, and they're really easy to calculate. There didn't seem to be any point in tracking things more closely than that. With all the other stuff they have to do, I figured that a tester could accomplish between one-and-a-half and two hours of on-charter work in the morning and in the afternoon. We could track time down to the hour, but why bother? Everybody would feel micromanaged, and it doesn’t serve any purpose. So our approach was a blend of session- and threadbased test management."