Re^6: An interesting rebuttal of "agile"

[chromatic]

That may be a result of the staffing available to me, but it makes more sense to me to bang around a release for a few days, and then say, "Well, no show-stoppers in the last few days -- let's release!"

I've also worked in very small teams where we had no dedicated QA. Even then, I have a severe distrust of the kind of ad hoc testing you get from banging around a release for a few days to see if any of the bugs in the product somehow appear. If anyone finds a bug, I want to find it, understand it, fix it for good, and then ensure that it and bugs like it can never appear again. I don't think you get that without serious testing and root cause analysis, and I know you don't get that often (if ever) if QA is a separate entity from development.

[jplindstrom]

If anyone finds a bug, I want to find it, understand it, fix it for good, and then ensure that it and bugs like it can never appear again. I don't think you get that without serious testing and root cause analysis, and I know you don't get that often (if ever) if QA is a separate entity from development.

Of course it's good to have embedded testers. But I don't think it has much to do with whether bugs get fixed properly or not.

Whether that happens or not seems to me to be more a function of the mindset of the developer, whether he concentrates on fixing the symptom of the bug or fixing-the-hell-out-of-the-bug(tm) once it is found.

/J