Testing strategies and their outcomes

Testing

Overview

A. Overview
We conducted numerous unit and integration tests to ensure that our overall solution was functional and robust. Since our product was aimed to be deployed in a public setting, it was also very important to conduct user acceptance testing. Hence, during development, we showcased compiled versions of our system to several other teams, as well as clients such as Great Ormond Street Hospital, allowing us to gather invaluable feedback.

Most features of the MotionInput, such as position tracking, gesture events, and keyboard triggers, require a live camera feed to function correctly. This means that a lot of features weren’t amenable to unit testing, which is supposed to be robust and replicable. Thus, we decided to utilize user acceptance and empirical testing for these features and utilize unit testing when appropriate.

Unit Testing

Strategy
The communication between MotionInput and the intermediary server is a critical part of our solution, since it is what enables the frontend to receive all the live tracking and status information, and what allows the backend to receive config changes from the frontend. This feature also runs independently of the camera feed, making it a good candidate for unit testing.

After careful consideration, we decided that the following features must be tested to ensure optimal bidirectional communication:  
-> Reliability: Whenever data is sent by either side, it should also be received without dropping.
-> Correctness: The data received should be the same as the data sent.
-> Robustness: The connection should be maintained via keepalive messages at a fixed interval.

To test these features, we used Python’s built-in unittest library. It provides several useful features such as automated test detection, multiple test execution, one-time setup at test startup, and a useful summary of all the tests conducted. We will provide a brief summary of the tests conducted to ensure that the key features we outline above are present.
A. Setup
Before conducting all the tests, we use the `setUpClass` method to initialize the client and server threads, independent of the main programs:
B. Reliability
For testing reliability, for example, we send multiple messages and check whether they are all received on the other side:
C. Correctness
For testing correctness, we send a random message from either side and check the same message is received:
D. Robustness
For testing robustness, we check whether we receive any keepalive messages if there has been no communication:
We also check if these keepalive messages are separated by the defined interval, which in our case is 1 second
Conclusion
Using these tests, we were able to identify and fix several bugs, such as keepalive messages not sending due to incorrect time calculations, and multiple messages being dropped due to insufficient queue sizes. After several improvements and changes, we were able to pass all these unit tests.

Integration Testing

Strategy
Since our solution consists of several individual components communicating with each other, it was essential to conduct integration testing to ensure all parts operated as intended.

As mentioned before, our solution is intended to be used in a dynamic environment and requires a live camera feed and a person performing gestures to properly test. Since these sorts of inputs are difficult to simulate via unit testing, we opted for empirical testing, where we would devise interactions and the intended responses.

We then deployed our complete solution and had a person perform the required actions to check whether these functionalities worked as intended. As an example, here are a few empirical tests that we conducted:
Test A: Move the Hand
Test: Moving the hand in front of the camera should move the abstract hand preview in the web extension frontend.

Result: Success. The movement of the abstract hand preview mirrors the movement of the hand in real life.
Test B: Highlighted Detection Edges
Test: Moving the hand towards detection edges should highlight the appropriate edge on the web extension preview.

Result: Success.
Test C: Trigger Key Press
Test: Moving the hand towards the detection edge should press the appropriate keyboard arrow key.

Result:
Success. We use a keyboard tester website to check which arrow keys are pressed and if they match with the performed gestures.
Test D: Change Swipe Sensitivity
Test: Changing swipe sensitivity on the web extension frontend should change detection edges appropriately.

Result:
Success. As we decrease the sensitivity, the detection edges become smaller, and so we have to swipe more to register a gesture.  
Test E: Change Settings through MFC
Test: Changes made from the MFC admin frontend should reflect in the WebExtension frontend automatically.

Result:
Partial success. In the below example, we use the MFC frontend to change the controlling hand to the left hand and set the swipe sensitivity at 60. The hand preview changes as intended, and so do the detection edges which become bigger to match the sensitivity of 60. However, the position of the sensitivity slider in the WebExtension frontend remains the same.
Test F: Quit MotionInput
Test: Upon quitting MotionInput, the WebExtension frontend status info section should notify the user that it is disconnected.

Result:
Success.

User Acceptance Testing

Feedback
We were fortunate enough to be able to present our work to the Great Ormond Street Hospital as well as our peers at different stages of development, gaining invaluable feedback each time. Some of the changes implemented include:
  • Removing Alpha Transparency from the Colour of the Detection Edges: This led to darker colours at the intersection of edges, where the alpha transparency would be combined. This confused a lot of users as they assumed this indicated some special interaction.
  • Highlighting the Edges upon a Successful Swipe: Most users were unaware of what the detection edges meant and assumed it was some sort of dead zone. Therefore, we added a highlight animation to implicitly let the user know that moving to one of these edges would trigger a swipe gesture. We also changed the colour from grey to green to connote positive user interaction.
  • General Performance: Improvements to the MotionInput backend to make swipe gestures more responsive.
  • Reducing Intermediary Server Overhead: So that changes from the WebExtension frontend were communicated quickly to the MotionInput backend without any perceived lag.  
We also received lots of interesting use cases and ideas that our solution could be used for. For example, one staff member at Great Ormond Street Hospital proposed that we could use the live sensitivity adjustment capabilities in a physiotherapy setting, where doctors could dynamically check a patient’s range of motion by adjusting the sensitivity and measuring how many times they could move within a given range of motion. We will take these ideas into account for future development.