Differences

This shows you the differences between two versions of the page.

--- report:dvp [2026/06/13 11:52] – [Ideation] team3
+++ report:dvp [2026/06/13 19:30] (current) – [Tests & Results] team3
@@ Line 630: / Line 630: @@
 === Tests & Results ===
+This chapter summarizes the testing strategy, the executed test cases, and their outcomes. The full detail lives in the TRAQUA Test Plan and Test Report; what follows is a condensed overview.
+== Test Management Strategy ==
+Testing for TRAQUA followed a structured, iterative approach aligned with the development sprints and the operational requirements of the smart bottle. Tests were planned, documented, executed, and evaluated at both the component and system levels, and synchronized with project milestones so they stayed current as functionality and architecture evolved.
+The following Table {{ref>tab:testroles}} shows the testing roles and responsibilities.
+<WRAP centeralign>
+<table tab:testroles>
+<caption>Testing Roles and Responsibilities</caption>
+<WRAP box center>
+| Team Member | Role | Responsibility |
+| Bernardo Alves | Test lead | Oversees the testing process, ensures milestones are met, coordinates review and approval |
+| Bernardo Alves | Backend test coordinator | Designs and executes tests |
+| Maria Włodarczyk | Documentation coordinator | Manages test plan/report consistency, maintains traceability |
+| Maximilian Salmi | Data and component tester | Prepares and maintains tests, ensures components meet the standard |
+| Guillem Rolduá | Stress tester | Stress tests each component to determine its limits |
+| Rieke Platthaus | Frontend test supporter | Validates interface feedback |
+| Inès Margand | Frontend test supporter | Validates interface feedback |
+</WRAP>
+</table>
+</WRAP>
+== Testing Approach and Criteria ==
+The strategy centers on **state-transition testing**, verifying the system's behavior as it moves between the defined water-safety states: **Safe**, **Warning**, **Unsafe**, and **Unknown**. The verification covers the full sensing → classification → actuation chain, including the BLE link between the ESP32 firmware and the React Native app. The **Unknown** state is exercised by simulating poor sensor quality (stale readings, BLE disconnects, malformed JSON payloads) to confirm the system fails safe rather than reporting a stale Safe verdict.
+  * **Entry criteria:** use-case documentation approved, test environment configured to mirror production (latest code in the main branch, React Native 0.80, Expo), valid/invalid test data prepared, test cases developed, and the test team ready.
+  * **Exit criteria:** all relevant test cases executed successfully, functional correctness validated against expected results, defects recorded and resolved, and the test report generated.
+  * **Suspension criteria:** scope change, critical defects, the base product failing to run on a testing device, or unavailable external dependencies/resources.
+== Testing Resources ==
+  * **Hardware:** ESP32 Wroom 32, OLED screen, TDS sensor (SEN0244), accelerometer, force-sensitive resistor, temperature sensor, magnetic reed switch, MOSFET, buck converter, battery pack (4× NCR18650B, 4S balancing), and supporting power/prototyping components.
+  * **Software:** Node.js, Arduino IDE, WebStorm (or similar IDE).
+  * **Tooling:** GitHub for test-case creation, tracking, management, and defect management; manual execution; PyCharm and pipelines for unit testing; Postman and PDF/Word for reporting.
 == Hardware tests ==
@@ Line 636: / Line 674: @@
 == Software tests ==
-Our software testing framework directly addresses functionality, performance benchmarks, and user experience using the specific strategies and tools from our workflow:Functional Testing: We validate our identified use cases and user stories by verifying the system's core behavior. This includes unit testing our individual JavaScript/TypeScript code modules within Webstorm using Node.js , as well as executing API endpoint tests via Postman. We also conduct integration testing across the ESP32 firmware and the React Native mobile application to ensure these components function correctly as a combined entity.  Performance Testing: To evaluate speed, responsiveness, and stability under a workload, we run performance tests focused on data volume, system load, and runtime. These benchmark tests are repeated 10 times to determine precise average results and standard deviations, ensuring the BLE communication link and backend data transmission remain stable over time.  Usability Testing: To ensure the system is intuitive and accessible, we conduct usability testing according to the System Usability Scale (SUS). This allows our frontend team to validate interface feedback , evaluate how easily a user can understand their water safety status (Safe, Warning, Unsafe, Unknown) , and confirm that the mobile application provides clear, responsive alerts
-Software tests comprise:
+Our software testing framework directly addresses functionality, performance benchmarks, and user experience using the specific strategies and tools from our workflow:
-(i) functional tests regarding the identified use cases / user stories;
-(ii) performance tests regarding exchanged data volume, load and runtime (these tests are usually repeated 10 times to determine the average and standard deviation results);
+**Functional Testing:** We validate our identified use cases and user stories by verifying the system's core behavior. This includes unit testing our individual JavaScript/TypeScript code modules within WebStorm using Node.js, as well as executing API endpoint tests via Postman. We also conduct integration testing across the ESP32 firmware and the React Native mobile application to ensure these components function correctly as a combined entity.
-(iii) usability tests.
+**Performance Testing:** To evaluate speed, responsiveness, and stability under a workload, we run performance tests focused on data volume, system load, and runtime. These benchmark tests are repeated 10 times to determine precise average results and standard deviations, ensuring the BLE communication link and backend data transmission remain stable over time.
+**Usability Testing:** To ensure the system is intuitive and accessible, we conduct usability testing according to the System Usability Scale (SUS). This allows our frontend team to validate interface feedback, evaluate how easily a user can understand their water safety status (Safe, Warning, Unsafe, Unknown), and confirm that the mobile application provides clear, responsive alerts.
+Software tests comprise:
+  - (i) functional tests regarding the identified use cases / user stories;
+  - (ii) performance tests regarding exchanged data volume, load and runtime (these tests are usually repeated 10 times to determine the average and standard deviation results);
+  - (iii) usability tests.
+== Test Cases ==
+The following Table {{ref>tab:testcases}} shows the executed test cases.
+<WRAP centeralign>
+<table tab:testcases>
+<caption>Test Cases</caption>
+<WRAP box center>
+| ID | Input Condition | Expected Action | Expected Result |
+| TC01 | Connect to the ESP32 | Log result | Connection successful |
+| TC02 | Wrong ID in connection | Log result | Connection not successful |
+| TC03 | Get TDS value | Log result | TDS value within 50–200 range |
+| TC04 | Get temperature value | Log result | Temperature value read in the app |
+| TC05 | Gravity sensor | Log result | Reads whether the bottle is tilted |
+| TC06 | LED light changes color | Log result | LED shows either green or red |
+| TC07 | Pressure sensor estimates water | Log result | Reads total water in the bottle |
+| TC08 | UVC light runs | Clean water | Water is cleaned |
+| TC09 | Reed switch | UVC to turn on/off | UVC must not run while the switch is connected |
+</WRAP>
+</table>
+</WRAP>
+== Results Summary ==
+A total of 9 test cases were executed, all of which passed. It must be noted that some aspects of the code could not be tested directly on hardware and were instead validated through simulation.
+The following Table {{ref>tab:testresults}} shows the test results overview.
+<WRAP centeralign>
+<table tab:testresults>
+<caption>Test Results Overview</caption>
+<WRAP box center>
+| Result | Number | Percentage |
+| **Passed** | 9 | 100% |
+| **Failed** | 0 | 0% |
+| **Total** | 9 | 100% |
+</WRAP>
+</table>
+</WRAP>
+All nine test cases (TC01–TC09) returned **Passed** with no recorded defects.
 ==== Summary ====
 This chapter followed the journey of TRAQUA from its idea to a working model. The team started with sketches and eventually decided on a smart water bottle with five main features: