The QA Environment: What It Is and Why Its Name Creates Problems
Given that UAT is reserved for external-facing testing against market infrastructure and external partners, your internal teams need somewhere else to test. That environment is QA — and the name is where things start to break down.
UAT is a term almost everyone understands. Say it in a room full of developers, business analysts, project managers, or regulators, and they all broadly know what you mean: the environment where acceptance testing happens before a release goes live.
QA does not carry the same shared understanding. Ask teams across different systems or business lines what they call their pre-UAT environment, and you will get a different answer from each one: SIT (System Integration Testing), INT (Integration), TEST, UAT2, STAGE, or simply "the lower environment." These are all names for the same concept, but the lack of consistent terminology creates real operational friction.
When teams across multiple systems are trying to coordinate an end-to-end test, ambiguity about which environment is being referred to leads to misaligned deployments, wasted cycles, and missed defects.
Whatever your organization chooses to call it, the concept must be clearly defined and universally understood: QA is the internal, controlled test environment that sits between development and UAT.
Why Three Environments Are the Minimum
The three-environment model — Development, QA, and UAT — is not a luxury. It is the minimum structure for testing responsibly at the enterprise level.
At any given moment, engineering teams are working on multiple things in parallel. There is the release scheduled for production in the next cycle. There are features and fixes that are in progress but not yet ready for that release. There are changes from other teams whose systems interact with yours.
QA is where everything that is not yet ready for release gets tested. Teams can deploy work in progress, validate behavior, surface integration problems, and iterate freely — without touching the environment that is supposed to represent what is actually going to production.
UAT, by contrast, should contain only the software that is going to production. Its job is to give business stakeholders, external partners, and acceptance testers a stable, production-like view of the upcoming release.
That stability is only possible if UAT is protected from in-progress work. And that protection is only possible if QA exists as a separate place for that work to live.
Posted on agilish.net — Enterprise Testing