How did Project Intelligence get started?
As part of an interview for the Empirix QAZone website, I was asked a series of questions. Here's one of them and my answer.
"Paul, you devised a very interesting concept of “Project Intelligence”, a corresponding framework and a course on this topic. How would you define it, and also can you share with QAZone a little about how it “started”?"
It all started with a keynote for Eurostar in 2002. The theme of the conference was “The Value of Testing”. At first, I thought this was a terrible theme – but it really made me think hard about what exactly the value of testing is. This was a tough one – it really focused my mind and it eventually turned out to be a great stimulus.
As a tester, as a provider – who are we to put a value on our ‘product’ – we’re not independent, are we?
So I thought it might help if we think like marketers for a moment and view testing as a service or a product. Would that help? Maybe if we think a little more like marketers we can enhance not only the value of our testing, but also of our customers’ perception of it?
To cut a long story short, I came to the conclusion that the only value of testing is in the information we provide to stakeholders, management, developers, authors. Essentially, testers measure achievement. It’s OK for project managers to monitor time and cost and activity status. But time and cost are inputs, not outputs and activity is definitely not the same as achievement. The real measurement of achievement is successful completion of the reviews or test of the products of those activities.
Products can be documents or code or systems. But I thought straight away that the disciplines of testing can also be applied to testing services provided by integrated people, processes and software. And then it occurred to me that we could apply the same measurement approach to all business benefits. Stakeholders want to achieve business goals – software is just an enabler – why don’t we offer to measure benefits too?
Now, all this was happening round about the same time as was writing the Risk-Based E-Business Testing book with my friend Neil Thompson. How does risk fit in here? And how about the traditional coverage-based approaches? It was getting messy. But then it became clear. We should define a strategy for collecting information to demonstrate achievement and address risk and with sufficient coverage to be confident in our decision making.
So why not propose a test strategy that aims to measure successful achievement of all technical and business goals?