Wednesday, September 01, 2010

--- 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.>

I'm not the Original Poster, but consider you are testing feature X. You break it down into tasks and say it will take 5 hours to "test."

The first build is total garbage. You can't even click the submit button.

The next day, you get a new build. You find five bugs. You get a new buildlate in the day - four of the five bugs are fixed, and you find three new ones.

You get the fixes in the morning on day three. You find another bug. At noon,your boss comes up: "You said this would take five hours to test and you are onDAY THREE of testing? Wassup with that?"

---> Bottom line, there are elements in how long it takes to do testing beyondthe testers control. It's generally possible to estimate a test /cycle/ withsome accuracy, but estimating the entire test /process/(*) is rarely possibleunless you know the devs very well and have had some stability in deliveredsoftware quality for some time.

Estimating in terms of points 'smooths' those gaps.

That's one possible explanation, anyway ...

--heusser(*) - Yes, this pre-supposes that testing is a separate and distinct activity, Iknow, we should be involved up front, whole team, etc. I'm with you. Butyou gotta walk before you can run. Let's have that discussion on a separatethread, ok?