Differences

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

--- report:dvp [2026/06/10 10:24] – [Functional Testing Results] team3
+++ report:dvp [2026/06/13 19:30] (current) – [Tests & Results] team3
@@ Line 16: / Line 16: @@
 Here the team already had the idea of keeping the components on the bottom of the bottle, but a more square bottle was kept in mind with a handle that would be comfortable for the user's hand.
-The second ideation of TRAQUA already has a more "classic" bottle shape (Figure {{ref>fig:ideation2}}).
+The second ideation of TRAQUA already has a more "classic" bottle shape (Figures {{ref>fig:ideation2}}).
 <WRAP centeralign>
@@ Line 39: / Line 39: @@
 The team also had a few changes in their flyer before coming up with the definite solution. Below we will explore the different flyers the TRAQUA design team came up with.
-The team's first flyer had no QR code; the text idea was already there, but the text just lies in boxes that feel out of place alongside the TRAQUA water bottle (Figure {{ref>fig:design1}}).
+The team's first flyer had no QR code; the text idea was already there, but the text just lies in boxes that feel out of place alongside the TRAQUA water bottle (Figures {{ref>fig:design1}}, {{ref>fig:design2}}, {{ref>fig:design3}}).
@@ Line 48: / Line 48: @@
 </figure>
 </WRAP>
 <WRAP centeralign>
-<figure fig:design1>
+<figure fig:design2>
 {{:report:flyerversion5.png?400|}}
-<caption>First design </caption>
+<caption>Second design </caption>
 </figure>
 </WRAP>
@@ Line 57: / Line 58: @@
 <WRAP centeralign>
-<figure fig:design1>
+<figure fig:design3>
 {{:report:traqua_fleyer.png?nolink&400|}}
-<caption>First design </caption>
+<caption>Final design </caption>
 </figure>
 </WRAP>
@@ Line 232: / Line 233: @@
 </figure>
 </WRAP>
+The final design is shown in Figures {{ref>fig:finaldesign}} and {{ref>fig:finalinside}}.
 <WRAP centeralign>
-<figure fig:model8>
+<figure fig:finaldesign>
-{{ :report:StressSim.png?600 |}}
+{{:report:image_traqua.png?400|}}
-<caption>Stress Simulation</caption>
+<caption>The final design of TRAQUA</caption>
 </figure>
 </WRAP>
 <WRAP centeralign>
-<figure fig:model8>
+<figure fig:finalinside>
-{{ :report:assembly-drop_test_1-image-1.jpg?600 |}}
+{{:report:bottle_updated.png?400|}}
-<caption>Drop Simulation</caption>
+<caption>The final design of the inner TRAQUA</caption>
 </figure>
 </WRAP>
-Finite Element Analysis (FEA) was carried out in SolidWorks to evaluate the bottle's mechanical behavior under two specific scenarios. First, a lateral static load of 100 N was applied to simulate a firm physical grip. The resulting maximum von Mises stress was only 0.203 MPa, showing that daily handling forces are mechanically negligible.
-Next, a 1.5-meter drop test was simulated. In this dynamic scenario, the maximum stress peaked at 133.7 MPa, with the impact forces heavily concentrated along the bottom edge of the bottle. To properly protect the internal electronics, two variations for the 0.8–1.0 mm aluminum body were analyzed. When using standard Aluminum the Factor of Safety (FoS) is 1.08. This prevents catastrophic structural failure but leaves a very tight margin against plastic deformation like cosmetic denting. Upgrading the main body to Aluminum (yield strength of approx. 276 MPa) increases the FoS to 2.06, providing a much safer margin.
+Finite Element Analysis (FEA) was carried out in SolidWorks to evaluate the bottle's mechanical behavior under two specific scenarios (Figure {{ref>fig:stresstest}}). First, a lateral static load of 100 N was applied to simulate a firm physical grip. The resulting maximum von Mises stress was only 0.203 MPa, showing that daily handling forces are mechanically negligible.
+Next, a 1.5-meter drop test was simulated (Figure {{ref>fig:assembly}}). In this dynamic scenario, the maximum stress peaked at 133.7 MPa, with the impact forces heavily concentrated along the bottom edge of the bottle. To properly protect the internal electronics, two variations for the 0.8–1.0 mm aluminum body were analyzed. When using standard Aluminum the Factor of Safety (FoS) is 1.08. This prevents catastrophic structural failure but leaves a very tight margin against plastic deformation like cosmetic denting. Upgrading the main body to Aluminum (yield strength of approx. 276 MPa) increases the FoS to 2.06, providing a much safer margin.
+<WRAP centeralign>
+<figure fig:stresstest>
+{{ :report:StressSim.png?600 |}}
+<caption>Stress Simulation</caption>
+</figure>
+</WRAP>
+<WRAP centeralign>
+<figure fig:assembly>
+{{ :report:assembly-drop_test_1-image-1.jpg?600 |}}
+<caption>Drop Simulation</caption>
+</figure>
+</WRAP>
 === Smart System ===
@@ Line 479: / Line 495: @@
 <figure fig:packaging>
 {{:report:packaging_solution_v3.png?800|}}
-<caption>Packging solution sales poster</color></caption>
+<caption>Packging solution sales poster</caption>
 </figure>
 </WRAP>
@@ Line 587: / Line 603: @@
-<WRAP centeralign>
+<WRAP group>
+<WRAP third column>
 <figure fig:setupchart>
-{{:report:setupflow.png?200 |}}
+{{:report:setupflow.png?240,400 |}}
 <caption>Setup flow chart</caption>
 </figure>
@@ Line 595: / Line 612: @@
-Smart device firmware — main loop (loop)
+<WRAP third column>
-<WRAP centeralign>
 <figure fig:mainLoopApp>
-{{:report:mainloop.png?200 |}}
+{{:report:mainloop.png?240,400 |}}
 <caption>Main loop functions</caption>
 </figure>
 </WRAP>
-Mobile application — BLE connection and data flow
+<WRAP third column>
-<WRAP centeralign>
 <figure fig:bleConnection>
-{{:report:bleconnection.png?200 |}}
+{{:report:bleconnection.png?240,400 |}}
 <caption>Ble connection function</caption>
 </figure>
 </WRAP>
+</WRAP>
 === 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 621: / 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 according to the [[https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html|System Usability Scale]].
+**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 ====
-//Provide here the conclusions of this chapter and make the bridge to the next chapter.//
+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:
+  *  UV-C sterilisation
+  * Temperature monitoring
+  * Water-Quality sensing
+  * Hydration Tracking
+  * Mobile app connection over bluetooth
+The design team chose the materials created a three-part structure and developed the look. They also made 3D models. Used computer analysis to ensure the aluminium body can handle normal use and survive a 1.5 metre drop.
+On the side the team specified the hardware, including an ESP32 chip that controls the sensors UV-C module and power. They also worked on the software creating an app with React Native, a web shop with Svelte and a backend with FastAPI. The team made sure the Bluetooth communication is secure, with pairing, encryption and input checks. They also came up with a eco-friendly packaging solution using recycled airbags.
+oving from design to prototype introduced several practical deviations: a ready-made flask replaced the custom body, the battery system shifted from a 3S to a 4S configuration due to the components received, charging was omitted, and an OLED display was added. Functional testing validated almost every subsystem — sensors, power delivery, UV-C control, and ESP32 communication all passed — with the charger being the single failure, caused by the battery-configuration mismatch.
+Overall, the prototype meets its primary functional requirements and demonstrates the viability of the TRAQUA concept. The next chapter draws the project to a close, reflecting on how well TRAQUA met its original goals and outlining the directions for future development.