If you have the resources to constantly do user acceptance testing, all the power to you. But there are others who have to live with restrictions such as limits on available resources, yet still have to provide a process that enables them to put software releases into production.

I prefer to move QA into the development process itself (from the design stage through implementation and to exploratory testing) in order to avoid all of the falderol around different types of builds.

If you have the resources to do a full, soup to nuts QA run through at every step of the development process, then, in my opinion, you're either overstaffed or some people need reassignment.

In my opinion, you need to do a development build when you've completed a significant piece of code and need to 'draw the line' somewhere; that's at the discretion of the development team. 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.

A milestone build is the next level up, and requires an actual collection of features and bug fixes that may end up being a release. That's probably triggered by the project manager. All of the development testing is performed, as well as more rigorous testing of the new features and bug fixes by an internal QA person.

A release build is a really, really clean milestone build that's been tested even more throughly. Code reviews have been done on the changes, and perhaps an outside QA team has also tried it out and liked it. This is blessed by the director of development. A release build is one that's finally released to the client.

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.

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