more qa stuff

docs/TESTS.MD

@@ -45,3 +45,7 @@ To manually run the workflow on your branch navigate to the GitHub Actions tab a
 #### Automatic Run
 
 The tests are run automatically on every push or PR to the main branch. This will run both the integration and unit tests.
+
+## Results of Tests
+
+This section has been added for the marker. For proof and evidence of the tests please visit the GitHub Actions and select the test workflow. Here you will find both the basic unit tests and integration tests being run and their results.

report/REPORT.md

@@ -127,11 +127,11 @@ The repo features fully functioning integration tests which is capable of testin
 
 #### Availability
 
-In order to enhance the availability of our software, we utilized tools from Amazon Web Services (AWS) and leveraged the benefits of a Layered Architecture. To manage website traffic, we implemented a load balancer to improve fault tolerance. This load balancer can automatically detect server issues and reroute traffic to operational servers. Furthermore, we used Terraform to configure our application to dynamically scale resources based on load, effectively handling peak usage times. Using autoscaling groups we ensure that a minimum of 1 service is always running for both the frontend and backend. If an error were to occur and a service to go down, the autoscaling group can recover the service. The Layered Architecture plays a crucial role in fault isolation, allowing us to address and resolve issues in one layer without disrupting the others. To ensure the robustness of our website, we conducted rigorous testing. This approach ensures that any potential issues are identified and rectified promptly, thereby maintaining the website’s availability. Finally, we deployed the website over a 1 hour period and simulated a expected load and the website did not run into issues or downtime. To test the availability of our system we ran simulated tests were certain containers were killed. We tested the systems availability and ability to recover from this and still maintain functionality. From our tests that we conducted where we deliberately killed both the frontend and backend containers we found that the system was able to recover and maintain functionality. The test plan showing the steps taken and the result are documented and can be found here [documented](../docs/MANUAL.md).
+In order to enhance the availability of our software, we utilized tools from Amazon Web Services (AWS) and leveraged the benefits of a Layered Architecture. To manage website traffic, we implemented a load balancer to improve fault tolerance. This load balancer can automatically detect server issues and reroute traffic to operational servers. Furthermore, we used Terraform to configure our application to dynamically scale resources based on load, effectively handling peak usage times. Using autoscaling groups we ensure that a minimum of 1 service is always running for both the frontend and backend. If an error were to occur and a service to go down, the autoscaling group can recover the service. The Layered Architecture plays a crucial role in fault isolation, allowing us to address and resolve issues in one layer without disrupting the others. To ensure the robustness of our website, we conducted rigorous testing. This approach ensures that any potential issues are identified and rectified promptly, thereby maintaining the website’s availability. Finally, we deployed the website over a 1 hour period and simulated a expected load and the website did not run into issues or downtime. To test the availability of our system we ran simulated tests were certain containers were killed. We tested the systems availability and ability to recover from this and still maintain functionality. From our tests that we conducted where we deliberately killed both the frontend and backend containers we found that the system was able to recover and maintain functionality. The test plan showing the steps taken and the result are documented and can be found here [documented](../docs/MANUAL.md). Isolation of services - by using a layered architecture and load balancers between the user-> frontend and frontend -> backend we have fault containment. Each layer is only responsible for a specific aspect of the application, if an issue occurs at one layer it can be contained and recoverable from. For example an issue with the backend resulting in the service dying is recoverable, as the AWS autoscaling group will recover the service with a new one. By using a load balancer between the frontend -> backend the frontend can continue to forward traffic to the same load balancer. Although some requests will be lost while the backend is being spun up, the use of a LB allows us to not have to pass the frontend a new link to the backend. One critique of our implementation is our lack of database replication, this has resulted in our DB being a single point of failure. Unfortunately due to time constraints we were unable to implement this and a load balancer in front of the db. Another benefit of our architecture is the replaceability of components. Specific layers can be replaced or upgraded independently.
 
 #### Reliability
 
-There were numerous techniques employed to achieve the high level of reliability that we had set at project conception. In the project proposal it was outlined to achieve the necessary level of reliability, the project should have unit tests that thoroughly covers the core functionality of the system. These tests should ensure that the system maintains expected behaviour. We used test driven development to implement the unit and integration tests that cover the entire functionality of our application and previously mentioned in the testing section. These tests are then used in a GitHub workflow to ensure that every time a code change is pushed to main the tests run to ensure the core functionality works before the code reaches main. The availability of dev tools for deploy, teardown, redeployment and tests enhances the developer experience. The workflow for tests can be run on any branch and they are also able to be run locally or through the GitHub Actions. For more information about running / adding / using tests please visit [documented](../docs/TESTS.md).
+There were numerous techniques employed to achieve the high level of reliability that we had set at project conception. In the project proposal it was outlined to achieve the necessary level of reliability, the project should have unit tests that thoroughly covers the core functionality of the system. These tests should ensure that the system maintains expected behaviour. We used test driven development to implement the unit and integration tests that cover the entire functionality of our application and previously mentioned in the testing section. These tests are then used in a GitHub workflow to ensure that every time a code change is pushed to main the tests run to ensure the core functionality works before the code reaches main. The availability of dev tools for deploy, teardown, redeployment and tests enhances the developer experience. The workflow for tests can be run on any branch and they are also able to be run locally or through the GitHub Actions. For more information about running / adding / using tests please visit [documented](../docs/TESTS.md). Actual results for the tests can be viewed in GitHub Actions by selecting the Test workflow. Here you can see both the unit and integration tests being run on and the results of these. The integration tests cover every route, every possible response, every possible response code, validates the db for changes and has full integration tests as well. The benefit of a layered architecture here allows us to connect the test container directly to the persistence and db layer and allows us to validate the state of the db after every call to the backend.
 
 Secondly, by deploying our application to Amazon Web Services, we remove the necessity to ensure the webservers running our application are working correctly. Through the shared responsibility model AWS is responsible for the infrastructure such as the hardware, software and networking that run AWS Cloud services. We then using terraform ensure the containers we deploy are reliable on AWS.
 
@@ -141,6 +141,10 @@ Maintainability has been achieved primarily by the abstraction of code and layer
 
 We also made the effort to use the same programming language for both the front and backend. This acts as a redundancy that even if our documentation is unable to effectively communicate our decisions or is no longer update, the developer should be easily able to read the codebase and understand the importance and inner working of each component of the system.
 
+#### Security
+
+By using a layered architecture, each layer can enforce its own security policies, reducing the risk of unauthorised access or breaches that could compromise the system or its data. The layered architecture also gives us a reduced attack surface, through the isolation of layers.
+
 ## Reflection
 
 Recognizing the complexity of this project, our team made a strategic decision to initiate the process as early as possible. We quickly grasped the magnitude of the task at hand, understanding that each component carried a different weight, with the report and video taking precedence. During the planning phase, we envisioned a more feature-rich product, but had to scale back due to the project’s demanding nature.