“I need your Test Strategy by Friday” said the Project Manager. I reply “I can’t have a meaningful strategy by then. I don’t yet have enough information about what we’re doing; not least because the documents upon which I would depend haven’t even been published in draft yet”. “Yes, but the plan shows the Test Strategy is due on Friday”. “It’s impossible to do it by then. But if there is something you need to know just ask me and I’ll do my best to tell you.” “No – I just need the Strategy”
Later in the same project.. “I need more statistics – I know you’re already providing me with numbers on execution, defect discovery, coverage, turnaround time, priority, build teams resolving defects and defect rejection rate, but it’s not enough.” Me:- “sigh”
Understanding Project Management
I wish it weren’t so, but I’ve had conversations like these many times. Apart from the fact that some project managers clearly have only a limited understanding of Project Management, this tells me an interesting thing. It’s that even they know that Testing is somehow the only part of the development process that’s truly measurable.
These project managers will tell you they value the coding much more than they are eager about the value of testing. In their minds coding is the act which produces the tangible asset. In fact testing, to these PMs, is just a regrettable cost and a delay to which their projects are subject. But despite this they don’t ask for any measurement of the process of programming. They could relatively easily get stats on lines of code written or modules built. But they don’t. Why is this?
Testing for the Facts
I believe that subconsciously even these most naïve Project Managers recognise that only Testing gives them FACTS. Everything, literally all of it, prior to testing is essentially just an opinion. “I’d like it to do this”, “I’ll design it like that”, “My code will be structured like this”, “The programs are all complete”. These are nothing better than beliefs. It’s only when we subject programs to Testing that the rubber hits the road. Or, all too often on projects like this, it’s something hitting the fan.
Testing provides the facts – “When I do this, the program does that”. This knowledge permits important decisions to be made about the software. They may lay bare the fact that the software is not good enough or indicate that it probably is. In the end the decisions still come down to opinions, but this time they’re based on facts.
The Value of Testing
Prior to testing there is the idea of an asset, but only the facts from testing turn the idea into an asset. When viewed in this manner Testing is far from being a cost but the activity which most specifically realises the value of the project; Testing creates value.
