update cypress docs

docs/automated-test-creation.md

@@ -0,0 +1,24 @@
+# Automated Test creation guide
+
+Use this documentation to assist in automated UI test creation.
+
+## Automated UI tests
+Before creating your automated UI test it is worth first considering:
+- What areas of the site under test will you be hitting? 
+- Are there currently usable test hooks/selectors in place that Cypress can use to interact with said page.
+- Can your test make use of existing Page Objects and if not what new Page Objects will you need to create in support of your test case/s being added.
+
+Our current UI automation structure is as such:
+- We have The E2E tests folder which then houses the regression tests. Within this folder you will see the test specs and some sub test spec folders for areas that may house clustered test areas such as trusts.
+
+- We also have the 'Pages' folder, this houses the page objects that we have in place for reusability and test transparency.
+>> - Within the Page objects we use an elements structure to make our various objects even more reusable - These should be named to both be clear and explicit to what said element covers.
+
+- When creating your test it is important to have the following tenets in mind:
+>> - Reusability: Could this test possibly be extended to cover or covered by existing tests? Also when creating page objects can we in any way make these more generic to cover any future features or site functionality.
+
+>> - Maintainability: Our tests should not be flaky and should give us a clear vision of the state of our system. Therefore when creating a test you must be mindful to use robust code that will hold up over time but also be easy to update should something like a html hook change or element of a page moves.
+
+>> - Test independance: Tests should be broken down into independent tests wherein if they fail you know exactly why and were said test is failing for quick triage. Its important that they aren't branching out or covering too many diverging paths and each cover a clear and concise test flow. 
+
+- For reporting we currently use Mocha reports - stipulations of this can be amended in the cypress.config.ts. This is also generated when we run in the pipeline.

docs/run-tests-locally.md

@@ -3,7 +3,7 @@
 Use this documentation to run tests locally.
 
 - [Unit tests](#unit-tests)
-- [Accessibility and UI tests](#accessibility-and-ui-tests)
+- [UI tests](#ui-tests)
 - [Security testing with zap](#security-testing-with-zap)
 
 ## Unit tests
@@ -16,80 +16,38 @@ You can run unit tests using your preferred IDE, or open a terminal in the proje
 dotnet test
 ```
 
-## Accessibility and UI tests
-
-Accessibility and UI tests are written using [Cypress](https://www.cypress.io/), with external dependencies mocked (e.g. the database) or bypassed (e.g. the auth). You can run the tests against a docker instance, or run the application locally.
-
-1. Ensure the Docker engine is running.
-1. Create the file `tests/DFE.FindInformationAcademiesTrusts.CypressTests/cypress.env.json`
-
-```json
-{
-    "url": "http://localhost/",
-    "authKey": "TestSuperSecret"
-}
-```
+## UI tests
 
+### Installation
 1. Open a terminal in your repository and run:
 
     ```bash
     cd tests/DFE.FindInformationAcademiesTrusts.CypressTests
 
     # install dependencies
     npm install
-
-    # run tests 
-    npm run cy:run # run tests in headless mode
-    npm run cy:open # run tests in headed mode
-
     ```
 
-If you need to update the mocked test data for UI and Accessibility tests see [update test data](./update-test-data.md)
-
-### Security testing with ZAP
-
-The Cypress tests can also be run, proxied via [OWASP ZAP](https://zaproxy.org) for passive security scanning of the application.
-
-These can be run using the configured `docker-compose.yml`, which will spin up containers for the ZAP daemon and the Cypress tests, including all networking required. You will need to update any config in the file before running
-
-Create a `.env` file for docker, this file needs to include
-
-- all of your required cypress configuration
-- HTTP_PROXY e.g. `http://zap:8080`
-- ZAP_API_KEY, can be any random guid
+2. DFE machines may have trouble running Cypress for the first time or installing dependancies due to internal proxies and auth. If in the instance this looks like its occuring on setup you will need to run the following command to bypass this for the installation.
 
-Example env:
-
-```env
-URL=<Enter URL>
-USERNAME=<Enter username>
-API=<Enter API>
-API_KEY=<Enter API key>
-AUTH_KEY=<Enter auth key>
-HTTP_PROXY=http://zap:8080
-ZAP_API_KEY=<Enter random guid>
-
-```
-
-**Note**: You might have trouble running this locally because of docker thinking localhost is the container and not your machine
-
-To run docker compose use:
+    ```
+    set NODE_TLS_REJECT_UNAUTHORIZED=0'
+    ```
 
-`docker-compose -f docker-compose.yml --exit-code-from cypress`
+3. Open a terminal in your repository and run:
 
-**Note**: `--exit-code-from cypress` tells the container to quit when cypress finishes
+    ```bash
+    cd tests/DFE.FindInformationAcademiesTrusts.CypressTests
 
-You can also exclude URLs from being intercepted by using the NO_PROXY setting
+    # run tests 
+    npx cypress open --> #This will run Cypress for the first time and notify you of such, it should then setup Cypress locally for you. 
+    ```
 
-e.g. NO_PROXY=google.com,yahoo.co.uk
+4. Once the above step is ran you should have the Cypress UI open showing your test specs - to run these you click on the test spec and it should then run all the tests within said spec.
 
-Alternatively, you can run the Cypress tests against an existing ZAP proxy by setting the environment configuration
+>- If the test passes you should see a green tick next to said test with confirmation that all tests within the spec are passing if multiple.
+>- If the test fails it should show you within the runner what the failed test step is with a screenshot of where it failed to help you in debugging the fail. (N.b Cypress will rerun the open spec everytime you save one of your open files)
 
-```env
-HTTP_PROXY="<zap-daemon-url>"
-NO_PROXY="<list-of-urls-to-ignore>"
-```
 
-and setting the runtime variables
 
-`zapReport=true,zapApiKey=<zap-api-key>,zapUrl="<zap-daemon-url>"`
+### Security testing with ZAP - Currently deprecated and will be reintroduced down the line

docs/test-approach.md

@@ -98,6 +98,10 @@ Our application is designed to support Microsoft Edge and Google Chrome laptop/P
 
 This testing is performed as required after a significant UI change. Results are recorded against the relevant "exploratory test" task in DevOps.
 
+Exploratory testing should use the testers experience with the product to direct their testing of the syste]m/s.
+
+A test charter should be used to bring structure to this testing including an entry and exit criteria, areas under test, bug recording and relevant test date.
+
 ### Functional testing
 
 #### Unit