Goal: Make scorecard easier to integrate in test pipelines and able to execute functional, Operator-specific tests shipped as part of the Operator metadata.

Benefit hypothesis: Operator authors are creating higher quality Operator because they more likely to create pipelines that leverage the Operator-SDK scorecard to continuously test basic aspects as well as functionality.

Why is this important: Operator quality is important to Red Hat, especially when it comes to Operators representing OpenShift Add-Ons or Partner integrations. Relying on (manual tests) by the authors does not keep up with OpenShifts release cycle and generic tests only tests a small portion of the Operators surface.

Acceptance criteria:

• scorecard can be used in a test pipeline offering configurability about test execution and machine-readable test results
• scorecard can be used to test functional aspects specific to the Operator using custom tests
• scorecard has a very low bar to create basic custom tests
• scorecard supports arbitrarily complex custom tests
• scorecard ships with generic tests that vet for OLM compatibility