Re^4: An interesting rebuttal of "agile"

About the only QA that happens on that build is something like a) check that all the files are there; b) check that all the tests pass; c) check that it installs and runs through a few basic user acceptance tests and is usable for further development.

I'm not going to waste my team's time wondering if the code works and is acceptable to the customer by throwing a binary wad over the wall to a bunch of pixel-clicking monkeys once a month, or once a quarter, or whenever. I want to know that we could take whatever's on the trunk and hand a CD to our customer within two hours, and he or she will be happy with the results.

Any development process with a wall between QA and developers has at least one huge flaw, in my opinion -- it takes way too long to know if you've built the right thing.

Comment on Re^4: An interesting rebuttal of "agile"

Replies are listed 'Best First'.
Re^5: An interesting rebuttal of "agile" by talexb (Chancellor) on Mar 19, 2008 at 13:42 UTC
I think it's pretty clear that your development environment and mine differ pretty widely -- which is why you can go from a development build to a release in a couple of hours, and I cannot. At my previous job, I was the only web developer. I was also the only 24/7 support person, and the only internal support persion. I also got the opportunity to bounce ideas off the CTO, and have him bounce ideas off me. My test persion was actually working full-time on Production and I had to schedule a few hours for her to get time to test a build (development sometimes -- milestone and release always). But I also strongly believe that it's important for software to released as a 'slightly used' version, rather than something fresh and hot from the repository and the QA department. 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!" Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^6: An interesting rebuttal of "agile" by chromatic (Archbishop) on Mar 19, 2008 at 18:21 UTC
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.	[reply]
Re^7: An interesting rebuttal of "agile" by jplindstrom (Monsignor) on Mar 20, 2008 at 14:35 UTC
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	[reply]