So we’ve had a bit of an adventure; I’ve covered three different estimation models, each with a basis that isactually sound. And there’s a problem. The problem is simple: We are presupposing that “tested” and “not tested” are binary statements. That there is some amount of testing that is “right” and it’s universal. Doing less […]
Test Estimation – VI
So far, we have two ways to predict project outcome: First by comparing the test effort to other projects, and suggesting it is “between the six of project X and projec Y”, this giving us a range. Second by calculating out test costs as a percentage of the development (or total project) effort, looking at […]
Test Estimation – V
So one way to estimate the testing phase (if you have such a thing), or at least testing activities, is to compare the test effort to the development effort or overall effort on other projects. Examples: “We spent about ten solid months on MaxStudio, and only spent two months testing. So I think testing should […]
Test Estimation – IV
So far, I’ve pointed out various issues in test estimation, pointing out the fallacies involved in simple ‘naive’ test estimation. I also pointed out that is possible to do some kind of estimate, even if all you say is “um, yeah boss — two weeks.” A couple of people expressed surprise at this. Laurent Bossavit, […]
Test Estimation – III
So previously I posted that factors outside our own control make accurately estimating the total test schedule impossible. In addition, I posted that even estimatingf simple, known, static things by breaking them into tasks, then adding up the tasks is much less accurate than you might think. Example Three: Imagine your typical workday that ends […]
On Test Estimation – II
Another post I made to the Agile-Testing Group recently: Here’s a simple estimation excercise. My honest advice is don’t just read it; actually try it. It takes about two minutes. To start, think about the space between the bottom of your feet and your knees. Write it down. Then think about the space between your […]
On Test Estimation – I
I posted this yesterday to the Agile-Testing List, thought I would share it here as well: — In agile-testing@yahoogroups.com, “daswartz@…” wrote:>>> Can you help us understand why the QA people care whether> you estimate in hours or points? I’m sure they have a reason, which> should help us better answer the context for your question.> […]
Estimates – III (Serious this time)
I’ve re-titled the last Estimates III as “Models – I”, as it really deserves it’s own serious. Pressing on … (AKA – Stupid Project Management Tricks; a True Story) The code is big stinking mess, all over the floor. The team is dependent on a vendor who hasn’t delivered a good build to us yet. […]
Estimates – II
As usual, some of my commenter’s have written my article for me … Seriously, Ben Simo points out that is it always possible to give an estimate, but that all estimates are wrong (if they were right, they would be commitments). Shrini points out that we get lousy requirements for our estimates. For example, when […]
Estimates – Laws
I’m a big fan of “Laws” of software development – Rules that express complex ideas in very few words. Moore’s Law, for example, that computing power doubles (roughly) every eighteen months. Or Jerry Weinberg’s advice to not attribute to malice what can be explained by incompetance. Or Paul Jorgensen’s rule of large numbers in software […]
Estimates – Interlude
The previous post was on estimates for technologist in general. Software Testers, things are a little more … challenging. For example – What quality will be the code be when it is delivered to test? Most of the time, we don’t know. Vast differences in quality could make testing take a longer – or shorter […]
Estimates – I
If I had to think of one subject that was not taught in school, and only covered in industry certifications in the most naïve way – it would be estimation. It seems so simple. You figure out what needs to be done, figure out how to do it, break the how down into tasks, and […]