Quality system
The Quality Assurance (QAS) system is where changes built in DEV are tested before they reach production. It is the gate that protects the live business, and its value depends on how closely it mirrors production.
QAS sits in the middle of DEV → QAS → PRD.
- QAS receives transports from DEV and is where functional, integration, regression and user-acceptance testing happen.
- Testing is only meaningful if QAS resembles production, similar configuration, representative data (often via a system copy from…
- Functional testing of the changed process.
- Watch out: QAS drifting from PRD, tests then lie.
What QAS is for
QAS receives transports from DEV and is where functional, integration, regression and user-acceptance testing happen. Only changes that pass here should be released to PRD. It is the proving ground that turns "it works on my machine" into "it works for the business".
Why it must mirror PRD
Testing is only meaningful if QAS resembles production, similar configuration, representative data (often via a system copy from PRD), and the same transport sequence. When QAS drifts from PRD, tests give false confidence and issues surface only after go-live.
Testing in QAS
- Functional testing of the changed process.
- Integration testing across modules.
- Regression testing that nothing else broke.
- User acceptance testing by the business.
QAS and the transport path
QAS sits in the middle of DEV → QAS → PRD. Importing transports into QAS in the correct order, and validating there before the same transports go to PRD, is core release discipline.
Common pitfalls
- QAS drifting from PRD, tests then lie.
- Skipping integration/regression testing.
- Releasing to PRD without QAS sign-off.