We have the same three environments - development, test and production. And yes, we have a different server for each environment, though I believe we are running all three as virtual servers on the same physical server. I don't know for certain, as I'm not involved on the hardware end of things. That's just my understanding.
We only give our users access to the production environment, and for that matter, only through Access Point. So users can only access their own copy of the document, not even the production server copy of the document.
We typically just install our new/fixed applications directly to the production environment, distribute the document to Access Point, and THEN let the users review the changes. If there's a need for a review before going live, we will typically have a meeting with the user and demonstrate the proposed changes from the development environment. However, we also typically read live production data even in the development environment, so this review is pretty indistinguishable from running on production.
I believe that at one time, very early in our QlikView implementation, we attempted to give users access to the Test environment, and to have them review applications there before going live. This apparently didn't work for us, and was quickly abandoned.
I should note that we do not run any mission-critical business systems in QlikView, and I cannot recommend doing so due to its limitations. QlikView is ONLY a reporting system. That gives us some wiggle room for installs, where if we accidentally break something the users are actively using, it might be a big headache, but it will NOT stop our business from running. That said, I can't remember a case where our lazy install process has caused any real problems.
Still, even our mission-critical business systems are structured similarly. Development, test and production, with users only having access to production. To demonstrate new features before going live, we sit down with the users and demonstrate them in development or test. Our testing and install procedure, however, is much more rigorous for the systems that actually run the business.
(Edit: On the development server, we do not have separate directories for each developer, nor do we have any official procedure for coordinating work done by multiple developers. The typical application only has one assigned developer, so problems are rare. There have been occasional minor headaches - I believe I've lost a couple minor changes when someone has saved over my work during some collaboration, and there was some miscommunication last week actually, where we had two developers working on the same application at the same time. Fortunately, one of the developers took their own copy of it, so it was just a matter of integrating changes rather than of developers stomping on each other's updates. An area in which we could improve, certainly, but nothing that has caused us serious problems that I'm aware of.)
