|
| 1 | +# Engineering quality-checks |
| 2 | + |
| 3 | +This is part of a broader [quality framework](README.md) |
| 4 | + |
| 5 | +# Summary |
| 6 | + |
| 7 | +Quality checks are at the heart of good engineering and are essential for rapid and safe delivery of software changes. This page provides an index of the various quality checks described within our principles, patterns and practices. |
| 8 | + |
| 9 | +# Usage |
| 10 | + |
| 11 | +We recommend all projects should apply all of the applicable quality checks |
| 12 | + |
| 13 | +Not all checks are applicable in all contexts, for example accessibility testing is obviously not applicable to products without a user interface |
| 14 | + |
| 15 | +## RAG scale |
| 16 | + |
| 17 | +We rate our projects against these checks as follows: |
| 18 | + |
| 19 | +* Green = check is applied frequently and consistently (typically via CI/CD), the output of the check is a quality gate (as opposed to just a warning / for information), and the tolerances for that quality gate (e.g. code coverage %) are agreed and understood |
| 20 | +* Amber = check is applied, but not all conditions for green are met |
| 21 | +* Red = check not in place |
| 22 | +* N/A = check does not apply in the context |
| 23 | + |
| 24 | +# Details |
| 25 | + |
| 26 | +| Quality check | Classification | Applicability | What it means | We we care | Tolerances for green | Endorsed tools / configuration | Further details | |
| 27 | +|:---|:---|:---|:---|:---|:---|:---|:---| |
| 28 | +| Unit tests | Functionality | Universal | Logic tests for blocks of code, e.g. methods | Fast & early feedback of logic issues| CI/CD builds fail if any tests fail | - | [Test practices](./practices/testing.md) | |
| 29 | +| Integration tests | Functionality | Universal | | | | | | |
| 30 | +| API / contract tests | Functionality | Contextual | | | | | | |
| 31 | +| UI tests | Functionality | Contextual | | | | | | |
| 32 | +| Secret scanning | Security | Universal | | | | | | |
| 33 | +| Security code analysis | Security | Universal | | | | | | |
| 34 | +| Security testing | Security | Contextual | | | | | | |
| 35 | +| Dependency scanning | Security | Universal | | | | | | |
| 36 | +| Performance tests | Resilience | Contextual | | | | | | |
| 37 | +| Capacity tests | Resilience | Contextual | | | | | | |
| 38 | +| Stress tests | Resilience | Contextual | | | | | | |
| 39 | +| Soak tests | Resilience | Contextual | | | | | | |
| 40 | +| Chaos tests | Resilience | Contextual | | | | | | |
| 41 | +| Code coverage | Maintainability | Universal | | | | | | |
| 42 | +| Duplicate code scan | Maintainability | Universal | | | | | | |
| 43 | +| Code smells scan | Maintainability | Universal | | | | | | |
| 44 | +| Dead code scan | Maintainability | Universal | | | | | | |
| 45 | +| Code review | Other | Universal | A second person manually checking a code change | Quality check by a human, as opposed to via a tool | Enforced & audited step within workflow | TBC | [Code review guidance](./patterns/everything-as-code.md#code-review) | |
| 46 | +| Accessibility tests | Other | Universal | | | | | | |
| 47 | +| Tech radar check | Other | Universal | | | | | | |
0 commit comments