Update testing.md

insights/review.md

@@ -167,7 +167,10 @@ You may wish to score each individual component or system separately for these a
 #### 9. Testing
 
 - We have great test coverage.
-- Testing is everyone's responsibility.
+- Testing is everyone's responsibility and test is a first-class concern.
+- We support all team members to practice good testing, including by holding no-blame sessions to discuss any automation tests we should have added, and what we can learn from having missed them initially.
+- We build code for testability.
+- Tests (including both test code and test coverage & whether there are gaps) are part of our standard peer-review process.
 - Repetitive tests are automated.
 - Testing is considered before each work item is started and throughout its delivery.
 - We use the right mix of testing techniques including automated checks and exploratory testing.

patterns/everything-as-code.md

@@ -70,6 +70,9 @@ While effective testing is the best way to detect bugs or non-functional problem
 - Is the code clear and simple?
 - Is the code layout and structure consistent with agreed style and other code? (please see [enforce code formatting](enforce-code-formatting.md))
 - Would it easily allow future modification to meet slightly different needs, e.g. ten times the required data size or throughput?
+- Is it [built for testability](../practices/structured-code.md)?
+- Are the automated tests positioned appropriately in the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html), triggered appropriately in CI builds, etc?
+- Are there any missing [automated tests](../practices/testing.md), e.g. edge-cases that have not yet been considered?
 - Have the non-functional requirements been considered (performance, scalability, robustness, etc)?
 - Are common security issues guarded against (e.g. [OWASP Top 10](https://owasp.org/www-project-top-ten/))? Including:
   - Is any new input data being treated as potentially hostile?

practices/structured-code.md

@@ -9,6 +9,15 @@
 - These notes are part of a broader set of [principles](../principles.md)
 - These practices should be read in conjunction with [architect for flow](../patterns/architect-for-flow.md)
 
+## Benefits
+
+The benefits of well-structured & clean code are profound & widespread, some highlights are:
+
+- Promoting *maintainability* by generally making the code easier and safer to work on
+- Supporting *building for testability*, which hugely reduces the risk and effort of practicing good testing
+
+The above are fundamental to supporting the [little and often](../patterns/little-and-often.md) delivery approach, which itself has many benefits and is at the heart of this framework
+
 ## Details
 
 - Good code structure is essential for maintainability.

practices/testing.md

@@ -26,6 +26,7 @@
 - **Quality is the whole team's responsibility**
   - Education on testing and testing principles should be important to the whole team.
   - Quality approaches should be driven as a team and implemented by everyone.
+  - Teams should consider running regular coaching / mentoring sessions to support colleagues who are less experienced in testing to grow their skills, for example by no-blame group discussions to identify edge-case tests which have so far been missed, tests positioned incorrectly in the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html), etc.
 
 - **Combining business knowledge with testing knowledge yields better quality outcomes**
   - Include business knowledge and critical thinking as part of assurance
@@ -49,6 +50,7 @@
     - Eg. using API testing tools to aid exploratory API testing
 
 - **Testing should be continually improved**
+  - [Peer reviews](../patterns/everything-as-code.md#code-review) must consider tests as a first-class concern - this includes tests that are present / have been added (e.g. whether they are positioned appropriately in the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html), whether they are triggered appropriately in CI builds, etc) and any tests that are missing, e.g. edge-cases not yet considered
 
 - **Testing is continuous**
   - Testing is a continuous activity, not a phase of delivery

principles.md

@@ -48,7 +48,7 @@ The following practices support the principle of building quality in.
 
 **Pair programming**. Avoid quality issues by combining the skills and experience of two developers instead of one. Take advantage of navigator and driver roles. Also consider cross-discipline (e.g. dev-test) pairing.
 
-**[Test automation.](practices/testing.md)** Use test-driven development: Write the tests hand in hand with the code it is testing to ensure code is easily testable and does just enough to meet the requirements.
+**[Test automation.](practices/testing.md)** and **[build for testability](practices/structured-code.md)** Use test-driven development: Write the tests hand in hand with the code it is testing to ensure code is easily testable and does just enough to meet the requirements.
 
 **[Protect code quality](patterns/everything-as-code.md)** to keep code easy to maintain.