Counterintuitive To Whom?

Really, even the journalists of SD Times ignore what QA might have been telling them:

It seems counterintuitive to think that the biggest time-sink in the application production life cycle would receive the least regard from development managers. However, a survey published by Forrester Consulting has revealed that this conundrum is the cold hard fact for many organizations.

The objective of Forrester’s “Problem Resolution Survey Results and Analysis” was to determine where developers and testers are spending their time and to learn what is automated and what is not. The biggest time drain, according to the managers, directors and executives who responded: investigating and resolving application problems.

According to Forrester, almost half of the respondents require more than an hour to document a problem, and a problem report uses six types of media on average. “That is interesting to us, given the large number of problems,” remarked Eldad Maniv, vice president of BMC’s Identify Software Business Unit.

The respondents spend almost three out of every 10 hours (29 percent) in various stages of troubleshooting: documenting, reproducing or testing. On the average, a problem takes six days or more to resolve, and one in four of the problems reported by a QA or test group are returned as irreproducible.

Of course, that’s not really news to those of us on the ground in QA. When I’m asked to estimate how long something will take, I have to shrug; if the application works, it will take a couple of hours to run through the test cases. If there’s something wrong, it will take until the ultimate deadline to not fix it.

The most time consuming part of QA is the defect process; it’s trying to figure out exactly what’s going wrong and reproducing it as best possible so the developers don’t ignore the issue report, and then it’s arguing with the developers that it is something wrong, and then it’s retesting the “fix” the developers put in, and then it’s reopening the issue / rearguing the point, and then it’s logging issues broken by the “fix,” and then it’s testing a fix that accidentally works, and then it’s watching for the fixed issue to resurface in a later build because someone overwrote the fix with old code, and then it’s ….

Well, you get the point.

That’s what Software Quality Assurance professionals who aren’t suck-ups have been saying, but it falls on deaf ears until a highly-priced analyst firm comes to the same conclusions.

Comments are closed.


wordpress visitors