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
+* 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](specflow-cucumber.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 **whole delivery team** must review the TSR and agree with its conclusions.
+* 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