Merge pull request #106 from CSSE6400/86

frontend, backend availability test plan write up

.gitignore

@@ -3,4 +3,5 @@
 *node_modules*
 *__pycache__*
 *report.log*
-*unibasement.txt*
+*unibasement.txt*
+.vscode/settings.json

docs/MANUAL.md

@@ -0,0 +1,33 @@
+# Manual Testing of the Application
+
+## Availability Tests
+
+### Test Plans
+
+#### Frontend Availability
+
+1. Run Deploy workflow. [Deploy Documentation](DEPLOY_TEARDOWN.MD)
+2. Visit AWS management console
+3. Visit ECS and open the cluster for unibasement ![Step 3](images/manual/frontend_3.png)
+4. Select unibasement_frontend
+5. Select tasks tab
+6. Click the running task ![Step 6](images/manual/frontend_6.png)
+7. Note the current time ![Step 7](images/manual/frontend_7.png)
+8. Press Stop on the task
+9. Return to the cluster view and refresh the page ![Step 9](images/manual/frontend_9.png)
+10. Refresh the view and note the time when the task returns to steady state
+11. The task should return to steady state within 5 minutes ![Step 11](images/manual/frontend_11.png)
+
+#### Backend Availability
+
+1. Run Deploy workflow. [Deploy Documentation](DEPLOY_TEARDOWN.MD)
+2. Visit AWS management console
+3. Visit ECS and open the cluster for unibasement ![Step 3](images/manual/frontend_3.png)
+4. Select unibasement_backend
+5. Select tasks tab
+6. Click the running task
+7. Note the current time ![Step 7](images/manual/backend_7.png)
+8. Press Stop on the task
+9. Return to the cluster view and refresh the page
+10. Refresh the view and note the time when the task returns to steady state
+11. The task should return to steady state within 5 minutes ![Step 11](images/manual/backend_11.png)

report/REPORT.md

@@ -129,7 +129,7 @@ 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. 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.
+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. 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).
 
 #### Reliability