- Forrester Councils
- Councils Overview
- log in
Posted by Margo Visitacion on March 5, 2010
I've been working quite closely with fellow analysts Dave West and Mary Gerush surrounding project estimation. Regardless if you're in the Agile world, testing is factored in (well, unit testing anyway), and if you're in the traditional camp, we've heard the same pain from a number of Forrester customers. No matter what methodology we use, there's not enough time to test. To combat that, testing organizations are attempting to build a livable, usable framework to provide them with information to battle for sufficient testing time. The problem is, there is no one way of looking at it. Nothing new here, estimation has been always been a challenge in project management. What is different, however, is that organizations are starting to take testing seriously; actually, let me expand that to taking quality seriously, and because of that, testing organizations are finding support in developing test estimation frameworks that can help them provide realistic estimates to gain enough time to test what's important. I've heard everything from 1.5 function points of testing for every function point of development to 40% of development time. I think it's time that we share what we know to help our fellow testers. Too often, it depends on:
Still organizations want something to hang their hats on, as a guide or as way to forecast resources. In order to do that, we've been talking to a number of vendors and customers about their testing practice and their testing tool practices (for upcoming report on the testing tools landscape). It's not surprising that we've not found a silver bullet, but we are starting to see some trends in estimation practices. Among the most common used methods are:
Most of these methods provide great foundations for building estimates. Function points do require the steepest learning curve; however, they can provide a good indication of size, which you can then convert to effort. To me, the most problematic is percentage of development effort. You just can't count on that. A very small development effort can require a significant testing effort, especially if the change has many dependent modules. Personally, I think that a combination of practices, such as use cases or story points, knowing your testers capabilities, plus historical effort are the most efficient way of getting a real perspective. So, I put it out there to you – what's in your test estimation framework?
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »