report:intro

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
report:intro [2026/05/13 20:30] – [Requirements] epsatisepreport:intro [2026/05/26 15:21] (current) – [Tests] team3
Line 150: Line 150:
 ==== Tests ==== ==== Tests ====
  
 +Before TRAQUA can be successfully deployed, it is essential to ensure that the entire smart water bottle system operates reliably and safely. This requires structured testing at every stage—from the physical sensors up to the mobile application —to catch bugs early and guarantee a seamless user experience. 
 +
 +Our testing focus centers on these key areas:
 +
 +  * Water-Quality Classification & States: The core of TRAQUA is its ability to accurately classify water safety into states (Safe, Warning, Unsafe, or Unknown) based on pH, TDS, and temperature readings. We test this full chain to ensure the physical bottle and the app always display the correct safety verdict.  
 +
 +
 + 
 +
 +  * Fail-Safe Interlocks (UVC Light): For user safety, the UVC disinfection light must never turn on unless the bottle is fully closed. We strictly test the magnetic reed switch connection to ensure the light safely deactivates if the interlock isn't met.  
 +  
 +  
 +  * Bluetooth (BLE) Connection Reliability: We need to verify that the ESP32 firmware and the React Native app communicate without a hitch. This includes testing how the app handles poor signal, packet loss, and automatic reconnection if the connection drops.  
 + 
 +
 +
 +  * Handling Bad Sensor Data: If a sensor sends corrupted data or disconnects, the system must handle it gracefully. We test "Unknown" states using simulated poor readings to make sure the app fails safe rather than showing outdated, dangerous data.  
 +
 +
 +  
 +  * Hydration Tracking Accuracy: To ensure consumer features work perfectly, we test the bottle's ability to detect actual drinking events, update daily goal progress, and accurately trigger the 12-hour idle reset logic.  
 +
 +
 +  
 +  * Component & Interface Performance: Using physical hardware (like the ESP32, OLED screen, and status LEDs) alongside frontend validation, we test to ensure that on-device alerts match the application's interface feedback instantly.
 ==== Report Structure ==== ==== Report Structure ====
 <WRAP round box 400px> <WRAP round box 400px>
  • report/intro.1778700642.txt.gz
  • Last modified: 2026/05/13 20:30
  • by epsatisep