The reason to test same code on different environments is because each environment has different characteristics that can help or limit performing different test scenarios and find different kinds of bugs. The way the company defines test environments depends on its needs, testing process and resources they can spend on it. Given that, what I describe here might not match what you have in your place:
- less realistic: many external systems might be mocked for different reasons (some infrastructure might be expensive to use or it might not been delivered yet)
- less stable, because frequent deployments of snapshots versions of software
Stage environment (called often Staging, CERT, or pre-production):
- more realistic as it is similar to production infrastructure
- more stable for many reasons: it already passed tests in QA environment and bugs in your code and code of other teams you rely on have been fixed; if it is visible to customers more effort might be taken by Operations department to keep it up and running; often used after code freeze, so no frequent deploys, unless a bug fix must be applied.
What realistic means here is that some end-to-end tests cannot be executed on QA environment, because there is no infrastructure required by those tests. Also, in QA you may not be able to find some integration bugs (false negatives, due to missing infrastructure) or bugs you find will not occur on Staging (false positives, if QA is mocking external systems in a wrong way).
Being more realistic, however, is not always a good thing. Staging is more like production so simulating some scenarios in Staging might be hard (if not impossible). Think, for instance, of payment system failure which is easier to simulate with QA environment with proper mocks.
Stability offers also different kind of trade-offs. More stable environment means your tests are more credible because their output is not dependent on system instability. However, you usually are obliged not to break system (perform negative scenarios) that would impact other teams using same environment.
There are companies that have also other environments in testing pipeline, both before QA and after Stage. In some companies, each team might have its own environment with external systems mocked (e.g., two teams may work on Web app: one team working on UI may have backed mocked).
In all places I worked for unit tests where not executed against any real environment with deployed system under test. Unit tests and some integration tests were rather mocking most system dependencies themselves at runtime.