Changes to team charter, plus some de-duplication and correction

quality-assurance/executable-specifications.md

@@ -0,0 +1,13 @@
+# Executable Specifications 
+
+## Background
+
+An executable specification is an expression of business requirements, usually in a language that resembles prose, which can be executed as automated tests.  [Reqnroll](https://reqnroll.net/), which is a fork of Specflow is an example.  This uses a 'Given - When - Then' syntax, which is the most common form of executable specification.
+
+## When to use executable specifications
+
+The downside of executable specifications is that they add an extra technology plus a layer of mapping code to a project.  In theory this is offset by the advantage that tests can be created in collaboration with business users as part of a [BDD](./bdd.md) process.  It is therefore our policy that an executable specification like Specflow should NOT be used except as part of a BDD process.  If a BDD process has not been used, it usually better to express the intent of tests by naming them well and making them easy to read.
+
+## Technology
+
+Specflow is no longer a supported technology.  We should take the opportunity to remove it from our code where appropriate, either by replacing the specification layer entirely, or migrating it to [Reqnroll](https://reqnroll.net/).

quality-assurance/test-strategy.md

@@ -18,19 +18,25 @@ Automation must be used when possible.
 We suggest that all teams using automation should adhere to these principles:
 
 * New functionality must be covered by passing automated tests (unless there is a legitimate reason not to).
-* Make use of test design patterns and principles.
-* Add tests at the correct level of the test pyramid – lower is better.
+* Test design patterns and principles should be used.
+* Tests should be used at the optimum level of the test pyramid – lower is better.
+* All functional code must have accompanying unit tests.
+* All API development must have accompanying API tests.
+* Testing at the UI level should be limited to a small number tests where possible.
+* There must be a compelling reason to use a gherkin-based layer (see [specific guidance](executable-specifications.md)).
+* Test code must be treated with the same care and attention as production code (including pairing on writing).
+* The team will maintain their automated test suite (test content, relevance and code quality) to ensure it adds maximum value.
 * All tests should be independent of each other.
 
 ### Manual Scripted
 
 * Manual scripted testing should only be used when automation is not deemed the best approach (e.g. too costly, not feasible, not applicable).
 * Tests will be created using appropriate test design techniques, e.g. risk based, decision tables, boundary values analysis.
-* The team will decide on where these manual tests will be stored and maintained; Azure DevOps or feature files are two examples.
+* The team will decide on where these manual tests will be stored and maintained; Azure DevOps is preferred.
 
 ### Exploratory
 
-* Exploratory testing should be used to verify quality in addition to regular automated and manual scripted testing.
+* Exploratory testing should be used to verify quality in addition to regular automated and manual scripted testing (see [specific guidance](exploratory-testing.md)).
 * Sessions should be planned with a charter (including time-box, area to review, personas).
 
 ---

quality-assurance/ukho-quality-charter.md

@@ -5,40 +5,28 @@ This is the UKHO Delivery Quality Charter - a set of objectives that will improv
 ## The Team
 
 * All members of the team are equal – there should be no differences between developers and testers in:   
-    * Permissions they have been assigned (e.g. permissions to access environments)
-    * Access to hardware or software
-    * Weight of opinion
-* Teams that are multi-disciplinary, cross-functional and equal achieve better results
+    * Permissions they have been assigned (e.g. permissions to access environments).
+    * Access to hardware or software.
+    * Weight of opinion.
+* Teams that are multi-disciplinary, cross-functional and equal achieve better results.
 
 ## Ways of Working
 
-* Planning, creating and executing tests (including manual testing) is the responsibility of **everyone** in the team
-* The role of the tester in the team is to **champion** quality assurance and testing at **all** stages of the development process
-* The team will use BDD for user-focused stories in the story refinement process (for more details see our '[BDD](bdd.md)' page)
-* To ensure the team is aware of the Test Approach and their role in delivering this, the quality champion will present the approach to the team early in a project 
+* Planning, creating and executing tests (including manual testing) is the responsibility of **everyone** in the team.
+* The role of the tester in the team is to **champion** quality assurance and testing at **all** stages of the development process.
+* The tester ensures that a test approach is created and agreed with an appropriate set of stakeholders.  The whole delivery team is responsible for the quality of the test approach, and for carrying it out.
+* The tester ensures that information about testing is gathered into a Test Summary Report (TSR), and that it is reviewed by an appropriate set of stakeholders.  The tester must ensure that all members of the team that have contributed to development understand the testing and agree with the conclusion of the TSR.
+* Test approaches should reflect the [UKHO Test Strategy](test-strategy.md), with appropriate levels of automated, manual and non-functional testing.
+
 
 ## Acceptance Criteria
 
-* Every story will have acceptance criteria added before being worked on
-* Acceptance criteria will not be changed without cross-team awareness
-* Acceptance criteria will be testable, i.e. capable of being proven true or false
+* Every story will have acceptance criteria added before being worked on.
+* Acceptance criteria will not be changed without cross-team awareness.
+* Acceptance criteria will be testable, i.e. capable of being proven true or false.
+* Testers should champion the use of good quality acceptance criteria.
 
 For more details see our '[Acceptance Criteria](acceptance-criteria.md)' page.
 
-## Test Automation
-
-* Write tests at the correct level of the test pyramid – **lower** is **better**
-    * All functional code must have accompanying unit or component tests
-    * All API development must have accompanying API tests
-    * Testing at the UI level is limited to a small number of happy-path tests
-* There must be a compelling reason to use SpecFlow (its use must not be a default position)
-* Test code must be treated with the same care and attention as production code (including pairing on writing)
-* The team will maintain their automated test suite (test content, relevance and code quality) to ensure it adds maximum value
-
-For more details see our '[Test Strategy](test-strategy.md)' page.
 
-## Manual Testing
 
-* Manual testing should never be a team's default test method and should only be used when the team agrees that full automation of a test is not feasible (e.g. the technical complexity is too high or the time taken to fully automate a test far outweighs the benefit of having that test automated)
-* When used, evidence of manual testing (e.g. screenshots) is not required
-* Exploratory testing is a valid form of manual testing and should be part of the test approach