From b68b8640ad40ba797fcde3e277d9cba545671728 Mon Sep 17 00:00:00 2001 From: Ezequiel <73295972+iw-ezequiel@users.noreply.github.com> Date: Mon, 25 Oct 2021 10:42:44 +0100 Subject: [PATCH 1/2] Update usage and RAG scale #206 --- quality-checks.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/quality-checks.md b/quality-checks.md index ad16609a..8058dd43 100644 --- a/quality-checks.md +++ b/quality-checks.md @@ -15,20 +15,22 @@ The checks are classified here based on the concerns they help to address: ## Usage -All applicable quality checks should be applied. Not all checks are applicable in all contexts, for example accessibility testing is only applicable to applications with a user interface. +All applicable quality checks should be applied. Not all checks are universal, i.e. applicable in all contexts. For example, accessibility testing is only applicable to applications with a user interface. The [Details](#details) section lists universal checks in black, and contextual checks in grey. The majority of these checks should be [automated](./patterns/automate-everything.md) via [continuous integration / continuous deployment](./practices/continuous-integration.md): the optimal sequencing of these checks within CI/CD pipelines will depend on the project's branching strategy, deployment strategy, etc. All of these checks are important, even where their purpose overlaps with other checks in the list. For example, comprehensive functional testing could be achieved without unit testing, instead only using the other functional test types on this list - this would result in a very long-running and inefficient test suite, precluding fast feedback and impeding rapid and safe delivery of software changes. For further details please see [test practices](./practices/testing.md), and especially the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html). +Although we separate resilience checks into their notional components, when it comes to implementation these may be joined up where useful. For example, an automated test suite may test the application for peak load and then drop down to sustained load in order to conduct a soak test. + ## RAG scale We rate our applications against each of these checks as follows: -* Green = the quality check is applied frequently and consistently (in practice this typically means [automated](./patterns/automate-everything.md) via [continuous integration / continuous deployment](./practices/continuous-integration.md)), 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 -* Amber = the quality check is applied, but not all conditions for green are met - for example the check generates warnings that may or may not be acted on -* Red = the quality check is not applied -* N/A = the quality check is not applicable +* Green = the quality check is applied frequently and consistently (in practice this typically means [automated](./patterns/automate-everything.md) via [continuous integration / continuous deployment](./practices/continuous-integration.md)), 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. +* Amber = the quality check is applied, but not all conditions for green are met - for example the check generates warnings that may or may not be acted on, or is executed on an ad-hoc basis and cannot offer a consistent quality gate guarantee. +* Red = the quality check is not applied. +* N/A = the quality check is not applicable. ## Tracking progress From f238a0d6083077f022d12084b9d57267c6ebf4db Mon Sep 17 00:00:00 2001 From: Ezequiel <73295972+iw-ezequiel@users.noreply.github.com> Date: Tue, 26 Oct 2021 13:19:04 +0100 Subject: [PATCH 2/2] Update quality-checks.md --- quality-checks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-checks.md b/quality-checks.md index 8058dd43..01e55e31 100644 --- a/quality-checks.md +++ b/quality-checks.md @@ -15,7 +15,7 @@ The checks are classified here based on the concerns they help to address: ## Usage -All applicable quality checks should be applied. Not all checks are universal, i.e. applicable in all contexts. For example, accessibility testing is only applicable to applications with a user interface. The [Details](#details) section lists universal checks in black, and contextual checks in grey. +All applicable quality checks should be applied. Not all checks are universal, i.e. applicable in all contexts. For example, accessibility testing is only applicable to applications with a user interface. The majority of these checks should be [automated](./patterns/automate-everything.md) via [continuous integration / continuous deployment](./practices/continuous-integration.md): the optimal sequencing of these checks within CI/CD pipelines will depend on the project's branching strategy, deployment strategy, etc.