Test Plan

**Software testing:**

* Earily iterations of software testing will be done entirely in simulation with no actual hardware hooked up. This is done to verify the behavor of the device is as expected. Fixing the critical bugs in the flow of the scheduler is significantly easier to do when the outputs can be easily dumped to a log file.
* After the core operation has been verified on the computer a breadboard can be used with similar compoents to verfy a more real world test case. This is the stage where majority of the software problems should be fixed. Test Devices should be made in order to provide the sensors with known repeatable data than can be done multiple times exactly the same way.
* Once the hardware has a working prototype that can be used together with real people along with already calibrated extenal sensors to have a control to compare the prototype against. Once real world testing begins it will be harder to get exact repeatable values. If the software fails in this stage it is sent back to the previous phases and the prototype is used along with new tests are implimented to try and find the source of the error. Prototype testing should be used to verfy correctness and not to debug.

**Hardware testing:**

* Device protoype will be tested using a breadboard for ease of debunging. In order to begin testing the hardware the software must be at least somewhat stable. Developement between hardware and software should overlap some to ensure the software is properly optimized for the hardware components. To test the hardware consistant test devices are required. A device should be made to move the prototype in all directions as well at rotate it. This testing is needed to calibrate the accelormeters as well as to make sure getting the required measurements at an acceptable degree of accuracy is even possible. Another test is needed to verfy the motion sensors are sensitive enough to detect breathing by gentely moving the device at a rhythmic rate, eventually once this process is tuned enough a real person can be used. The heart rate sensor is simiplier to design, as it is just an IR emitter and detector, so real human beings along with an acurate store bought heart rate monitor can be used to test the prototype.
* Having a standardized testing system allows for easy comparisons of different prototype verisons to be made, making it easier to see any improvements or regressions caused by the change in design.
* Once development progress has advanced far enough real world tests can be used to verfiy behavor of the device as used by a real human. Human motions are not as percise as a machine's and the device needs to work with people. If the behavor is only tested on best case seneriors then some crucial factor might be overlooked. Furthermore design choices that might help performance might make the expirence worse for the user, by adding weight or being uncomfortable, so it is important to try the device out on its market target well before it is finalized.

**Durability and longevity testing:**

* Longevity tested will be done by putting several of the product in a high use enviroment with not realitic load for a significant period of time. From the failiure rate of the sample units the longevity of the product can be infered
* Real World long term use over a few years is impossible to complety predict ahead of time, however this constant use, high-intensity non realistic testing can give an idea of how robust the system is.
* Durability testing is best done manually, having the unit be droped, put in water, stepped on, etc. Putting the device in situations where it realisticlly could find itself in durring reasonable use is enough to verify the durability of the product