Cypress doc updates

docs/adrs/0013-private-gias-trust-contacts-data.md

@@ -12,7 +12,7 @@ Currently, the private GIAS (Get Information About Schools) data, which includes
 
 At present, the private GIAS data is received weekly in a spreadsheet. An individual manually inputs this data into KIM, from which it is pipelined into the Academies DB. FIAT then retrieves the data from Academies DB. However, due to the limitations of KIM, we are currently missing emails for CFOs and Chairs of Trustees in FIAT, creating gaps in our data.
 
-To resolve this, we have decided to bypass KIM for this specific dataset. The weekly GIAS spreadsheet will be fed directly into the Academies DB, populating a new table called `TadTrustGovernance`. This ensures that all required email addresses (including those of CFOs and Chairs of Trustees) will be captured accurately. The `MstrTrustGovernance` table, which sources its data from KIM, will no longer be used for this purpose. 
+To resolve this, we have decided to bypass KIM for this specific dataset. The weekly GIAS spreadsheet will be fed directly into the Academies DB, populating a new table called `TadTrustGovernance`. This ensures that all required email addresses (including those of CFOs and Chairs of Trustees) will be captured accurately. The `MstrTrustGovernance` table, which sources its data from KIM, will no longer be used for this purpose.
 
 As an interim solution, a member of the data team will manually download the GIAS file and pass it to the data engineer who will load it into the `TadTrustGovernance` table. In the future, this process is intended to be automated, where the file will be saved in a designated storage location and automatically loaded into the appropriate table by a data pipeline. At that point, the data will be moved into a different schema (`gias-nonpublic`), as the `tad` schema is temporary and will be phased out.
 

docs/adrs/0017-create-new-cypress-suite.md

@@ -0,0 +1,33 @@
+# 16. Create a new Cypress test suite to replace both the old Cypress suite and old Playwright suite
+
+**Date**: 2024-10-08
+
+## Status
+
+Accepted
+
+## Context
+
+The old Cypress suite was not quite fit for purpose for both test and development use cases.
+
+The tests used a journey based test approach which does not quite fit the flow and layout of FIAT. It also did not fully replace/encompass that which existed before it in the Playwright tests.
+
+From a test perspective the old suite did not quite hit the target of being easy to understand from someone from a test background who may be less experienced with coding and more developer based knowledge sets.
+
+From a dev perspective the old suite did not quite give them the confidence that their code was being adequately tested.
+
+## Decision
+
+The decision was to create a new Cypress suite that both encompassed the old Playwright coverage and create a Cypress suite created from the ground up with a test mindset behind each part of said suite.
+
+This was then worked on my Test in close tandem with the Dev team ensuring that no old coverage was missed and that we also captured all requirements from test and dev.
+
+We also adapted the pipeline to be more in line with the new suite as previously we had deployment tests and the UI tests but we landed on just having a dedicated UI test run.
+
+As part of the work we also assessed the previously used docker/faker system and moved this away to pointing at test and dev as they are closer to what the live product is like and give us more confidence rather than running against hard coded/faker data.
+
+## Consequences
+
+The end result was a robust suit of over 60 tests that not only captured old covered functionality but expanded upon and brought more confidence to the tech team.
+
+We now also have a good jumping off point to create new tests in as the sprints go forward.

docs/automated-test-creation.md

@@ -0,0 +1,31 @@
+# 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.
+
+### Rough automated UI test creation flow
+
+1. Create a branch for your feature/s under test
+2. Create the test spec file/s (.cy.ts) - If this is a sub category area of the site like trust for example this may need to be allocated a sub folder within the e2e test section.
+3. Next we will want to set up any page object pages you may need for the creation of your tests - this is created at the Cypress folder level and not the e2e folder level.
+4. Now we have the correct files created we want to start creating our elements and other supporting code in the page objects so we can start making the building blocks for the tests to pull from.
+5. Now the building blocks are in place we want to use these to create test steps in our test spec/s - running the test throughout the creation of each step to ensure we are creating the test as desired and all the elements, functions, methods, classes etc are working correctly.
+6. Once our test is created and passing (having checked it multiple times to ensure that the test will not flake out and ran negative tests of any assertions to check for false positives) we can push our code up for a PR and then hopefully merge said tests into the wider suite.

docs/run-tests-locally.md

@@ -3,8 +3,7 @@
 Use this documentation to run tests locally.
 
 - [Unit tests](#unit-tests)
-- [Accessibility and UI tests](#accessibility-and-ui-tests)
-- [Security testing with zap](#security-testing-with-zap)
+- [UI tests](#ui-tests)
 
 ## Unit tests
 
@@ -16,19 +15,9 @@ You can run unit tests using your preferred IDE, or open a terminal in the proje
 dotnet test
 ```
 
-## Accessibility and UI tests
+## 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"
-}
-```
+### Installation
 
 1. Open a terminal in your repository and run:
 
@@ -37,59 +26,26 @@ Accessibility and UI tests are written using [Cypress](https://www.cypress.io/),
 
     # 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
-
-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>
+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.
 
-```
-
-**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:
-
-`docker-compose -f docker-compose.yml --exit-code-from cypress`
-
-**Note**: `--exit-code-from cypress` tells the container to quit when cypress finishes
+    ```bash
+    export NODE_TLS_REJECT_UNAUTHORIZED=0'
+    ```
 
-You can also exclude URLs from being intercepted by using the NO_PROXY setting
+3. Open a terminal in your repository and run:
 
-e.g. NO_PROXY=google.com,yahoo.co.uk
+    ```bash
+    cd tests/DFE.FindInformationAcademiesTrusts.CypressTests
 
-Alternatively, you can run the Cypress tests against an existing ZAP proxy by setting the environment configuration
+    # 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. 
+    ```
 
-```env
-HTTP_PROXY="<zap-daemon-url>"
-NO_PROXY="<list-of-urls-to-ignore>"
-```
+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.
 
-and setting the runtime variables
+    - 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)
 
-`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