Just went to a TISQA meeting last night and the topic was ROI. Shaun Bradshaw of Questcon Technologies gave a great presentation. There's tons of graphs out there, but try to find one like I saw last night. It has the different areas separated (can't give the 3d graph so maybe this will help)
Shoot...forget the 2d drawing....anyway, the cost of fixing bugs in the end is less the more you invest in "testing" in the early stages of the sdlc.
It's hard to draw, but basically investing in QA earlier in the SDLC has a great ROI. (as opposed to waiting for "test" to get QA involved. He also talked about the overall view of QA = testing, whereas it need to change to QA = Quality throughout the sdlc.
Also, it was brought up that QA should be a separate group from "test". Does anyone else have this setup where they work? There was one person who said they did (out of 30 or so). QA and always been synonymous with test from what I've experienced.
I frequently see the "1:10:100" ratio trotted out in dicussions about QA.
QA catching a bad requirement is 10x cheaper than fixing a bug in test, and fixing a bug in test is 10x cheaper than letting a bug into production. So it pays to have QA up front to the tune of 100x the QA guy's salary, I guess.
It's a point well-taken but I think anyone can recognize that it's also jive, because nothing in life is "1:10:100". It would be nice to see some hard numbers but I can't imagine a situation where hard numbers could be gathered.
Re: QA separate from testing, I am kind of in that situation myself, but it's a pilot program and not org-wide. At the beginning of my project I was put into a QA role; I and another guy are directing all the QA activities (requirements review, test case design, project health metrics) but we typically do not execute the tests ourselves.