After taking the Black Box Software Testing (BBST) Foundations course, I decided to try taking a CDT approach with my next project. As it happened, my next client project was part of a larger Enterprise release, at a large bureaucratic organisation, with multiple other test teams already using established testing processes and procedures.

I was brought in as the Test Team Lead with 2 Test Analysts. On Day 1, the Programme Test Manager (PTM)  handed our team an incomplete and out-of-date requirements document, which had been prepared by the development team and signed off by the business (yes, really). This document had been approved by all stakeholders, despite the most pertinent section of the document consisting of only a heading, with no content. This is when I really understood James Bach‘s comment about testers having a super power – the ability to read.

By lunch time I was asked by the PTM how many test cases my team would need for this release. I protested the futility and absurdity of the request (I was more diplomatic at the time). Why is the number of test cases a useful measure, when tests might take 10 minutes or 2 days to execute? If we do write a certain number of test cases, won’t that number be ever-growing anyway as testers learn more about the product? How can I predict total number of test cases using only an incomplete requirements document? But in the end, a number was needed, so I offered to make up a number – 300 test cases. I was frowned at, and told that a more complex product in the same Enterprise release had predicted only 250 test cases, and that surely we would need less than them. I changed my answer to 200 test cases and that got a smile. I felt that I had given the right answer. But my CDT approach was not off to a great start.

Note: I first presented this information at OZWST 1 in the form of an Experience Report.