Quality Gates & Outlook

This page describes when a level passes, which tests run at each gate, and which extensions are planned. It is part of the Testing Concept.

Quality Gates

Each level has a defined scope and a defined result that it releases.

Entry and Exit Criteria

Each test level has entry and exit criteria. They are part of the Definition of Done for relevant changes.

	Examples
Entry criteria: when a test can start	Required test data is available. The target environment is reachable. Preconditions from earlier levels are met. The functional test scope is clear.
Exit criteria: when a level passes	All mandatory tests pass. Deviations are documented and accepted. Open defects are outside the approved scope. The next level can start with stable preconditions.

Gates

Gate	Goals	Typical tests
Commit (developer)	Fast feedback on each change; short wait times; reliable detection of small defects	Unit tests, small component tests, local API checks, frontend component tests
Merge request	Verify that a change works in an integration context; make regression risks visible	Targeted integration tests, Bruno API flows, selected Playwright or AuthZ E2E scenarios, smoke tests for affected components
Release and acceptance	Validate the complete platform in a production-like environment; combine functional and operational assessment	System tests in VCluster, community E2E and UAT, security approvals, documentation review, smoke test review with DevOps

Outlook

The following items are not part of the target state. They are planned extensions.

Medium-Term

1. Separate test levels into merge request, nightly, and release runs. Fast tests run in the merge request, broader runs each night, and complete acceptance flows before releases. This balances feedback speed and coverage.
2. Define an explicit smoke test suite. A small, mandatory suite, clearly separated from regression and integration tests, in close coordination with DevOps.
3. Measure quality indicators. Pipeline duration, flaky test rate, coverage of critical use cases, number of open test gaps, and test-related causes of release delays.
4. Trace requirements, tickets, and tests. A continuous mapping from functional requirements to tickets and test cases, supported by labels and references.
5. Add test obligations to the Definition of Done. Clear expectations for test scope and types for each change.
6. Combine the test libraries. Community E2E and developer E2E and system tests use the same test cases.

Long-Term

1. Accessibility checks and visual regression. Systematic accessibility testing and protection against unintended visual frontend changes.
2. Performance and load tests for critical paths. Login, core APIs, central E2E flows, and startup behavior, to find bottlenecks and scaling limits.
3. Security baseline in addition to the penetration test. Dependency scanning, secret scanning, container and image scanning, and basic misconfiguration checks.
4. Observability for tests. Useful logs, metrics, and error messages in test environments for faster root cause analysis.
5. Test maintenance as a separate process. Regular maintenance of the test library, removal of obsolete scenarios, and refactoring of the E2E and integration test foundation.