Lesson 4 of 6
Common quality gates
10 min
Listen to this lesson
A quality gate is a checkpoint where work is assessed against agreed criteria before it moves on. Projects at Contoso already pass SAP Activate quality gates; releases pass entry into regression and the go/no-go. The TCoE's job is to make the criteria common, so that "ready for UAT" or "ready for production" means the same thing on every project and every release.
The gate catalog
- Explore exitStrategy gateTest strategy approved; risks and regression impact identified
- Realize, before SITIntegration entryUnit and string tests complete; ATC clean for priority 1; data and users ready
- Realize, before UATUAT entryIntegration exit met; testers trained and released; UAT tests approved
- DeployGo/no-goExit criteria met or risks accepted by name; regression of shared processes passed
- Run, per releaseRelease readinessTargeted regression complete; readiness assessment issued
SAP Cloud ALM has a Quality Gates capability for exactly this: a predefined checkpoint where the project is assessed against quality criteria, which can be imported from SAP Activate roadmaps. Contoso keeps the standard criteria as a checklist the TCoE maintains and attaches the test completion report and evidence to each gate, so the decision and its basis sit in one place.
Standard entry and exit criteria
| Gate | Entry or exit | Standard criterion |
|---|---|---|
| Integration test | Entry | Build in CMQ; unit tests passed; no open severity 1 defects from string tests; test data recipes run; test users with production-like roles |
| Integration test | Exit | 100% of planned tests executed; 0 open severity 1; severity 2 only with an agreed workaround and owner; all defects triaged |
| UAT | Exit | All critical processes accepted by named process owners; open defects listed with owners and dates |
| Release readiness | Exit | Targeted regression scope executed; no new severity 1 or 2 in regression; deviations accepted by name |
Standard criteria the TCoE publishes. Projects may tighten them; loosening needs a recorded waiver.
The readiness assessment format
Every release and project go/no-go receives the same readiness assessment from the TCoE, so decision makers learn to read it quickly. sap-tst-307 teaches how to build the evidence pack behind it; the standard fixes its shape:
| Section | Content |
|---|---|
| Scope | What was tested, against which release content, in which system and client |
| Results | Executed, passed, failed and blocked, by critical process |
| Open defects | Severity, owner, workaround and target date for each |
| Waivers | Each unmet criterion, its residual risk and who accepted it |
| Recommendation | Go, go with conditions, or no-go, with the conditions written as checkable statements |
The standard readiness assessment. It is presented as given; the accountable owners decide.
Severity: one scale for everyone
| Severity | Definition | Contoso example |
|---|---|---|
| 1 Critical | A critical process cannot be completed; no workaround | Billing documents cannot be created for any sales order |
| 2 High | A critical process is impaired; a workaround exists but is costly or risky | Partial deliveries must be billed manually |
| 3 Medium | A non-critical function fails, or a critical one has an easy workaround | A pricing report shows the wrong column order |
| 4 Low | Cosmetic or documentation issue | A label is misspelled in a custom Fiori app |
Contoso's severity scale. Severity describes business impact; priority (how soon to fix) is set separately in triage.
Severity and priority are different fields. Severity is the business impact and is set by the tester and confirmed in triage. Priority is how soon to fix and is set by triage against the release date. A misspelled label on a customer-facing form might be low severity but high priority. Keeping the two apart stops arguments about one number trying to mean two things.
Defect workflow standard
Waivers: how a criterion is set aside
- RequestProject or release lead names the criterion and why it cannot be met
- AssessTCoE states the residual risk and any mitigation
- DecideThe accountable owner (process owner or release manager) accepts or rejects
- RecordWaiver stored with the gate in SAP Cloud ALM, with the name and date
- ReviewQuality council sees all waivers each quarter
What would you do?
During integration testing, a defect stops billing documents being created for partially picked deliveries. The project lead wants it logged as severity 3 "because only some deliveries are affected" so that the exit criterion of zero open severity 1 defects is met. Maria, the O2C key user, says partial deliveries are about 15% of Contoso's volume and billing them by hand is error-prone. What severity fits, and what happens to the gate?
- Publish one gate catalog with standard entry and exit criteria; projects may tighten, never silently loosen.
- SAP Cloud ALM Quality Gates can be imported from SAP Activate roadmaps; attach evidence and the completion report.
- Use one severity scale based on business impact; set priority separately in triage.
- Only a passed retest closes a fixed defect; deferral and waivers need a named accountable owner.
Check your understanding · not graded
Lesson check
1. What is the difference between severity and priority?
2. What closes a fixed defect under the TCoE workflow standard?
3. A project cannot meet the integration exit criterion of zero open severity 1 defects. What must happen?
4. What can SAP Cloud ALM quality gates be imported from?