Readme First - Internal QA Onboarding Process

 


Welcome

The concept of the Path Check Covid Defense/Aware app is for health and safety of the public. It is an open source product with a git repository that is HERE. The website is HERE and you can learn more about the goals of the app and people behind it on that page.

The QA role in this group is to not only verify that the app is functional in all manners that it defines for itself (which may have differences between each version, custom tailored to each Health Authority), but also that all Fit and Finish issues are conveyed to the developers with an eye on the customer experience in mind. Public facing technical issues are important, language translation is important (please see the listing of languages mapped to HA distribution HERE), and user interface are important in making a user-friendly app that will hopefully have a high participation level - in order to save lives.

There are Volunteer Testers coordinated by@Jonathon Wright of Vivit Worldwide (LINK). The Volunteer force is dependent on their expertise in both management and technology. To note: They are on Slack Please see @Arthur Gibson for details.

There is a high-end security team that is run by Tuik security (LINK). They are largely independent, but when an issue arises, will coordinate with internal QA for compliance of information handling measures. Please see @Arthur Gibson for details.

Currently the team uses Jira for tracking of both bugs as well as tracking stories. The current format is the Kanban lanes.

TO NOTE: Some of the documents here in the confluence area may be outdated. The pages HERE are filled with good information about how the product works and the mechanics behind the functionality, however, as with any software, the information becomes stale as the project continues. I would recommend that you consult @Arthur Gibson for specifics that need clarity for you - and that you update the pages as you progress, change formats or platforms.

Please continue on. The roadmap - in my opinion - would be to complete reading this page, continue on to see the items in How to Test - GAEN Solution, specifically the next page Getting set up with iOS or Android (OLD), and when you feel confident with the app continue to GAEN Mobile App Quality.


Basic Functionality of the Product

This app revolves around the GAEN (Google Apple Exposure Notification) format for informing the user if they have been within a 6ft range (bluetooth range) of a person that has received a positive test for COVID-19 within the last 14 days.

It does so by having the device generate random anonymous keys, exchanging these keys with other devices that have Exposure Notification set to ON and bluetooth enabled, and pinging the Health Authority’s server for validation. The app explains this principal in the onboarding slides. The requirements for this functionality are different for iOS and Android currently: iOS requires Bluetooth and Exposure Notification to be on, while Android requires Bluetooth, Exposure Notification and Location.

The idea is that when a user is tested, if the test returns positive, the user can get in touch with a Contact Tracer who will give them a Verification Code that can be entered into the device. The device will then contact the HA’s jurisdiction’s server and send the keys generated by the positive user’s device. The server will then be able to update any user that has received these codes. Having a match to one of these codes will create an Exposure Notification - it will tell the user that they have been in contact with someone that has tested positive. It should also denote a general time frame (ex: 7-14 days)

To note: the Contact Tracer uses a Health Authority interface to generate these codes. Their servers are not always the same for different HAs. We have a map for which HA corresponds to which jurisdiction server for Verification Code Generation. That can be found HERE, please contact @Arthur Gibson for further information and access.

For testing purposes, the developers have included a debug menu in the Settings page. The “EN Debug Menu” has a tool “Simulate Exposure” which will yield a randomized exposure notification. To note: this data does not leave the device and does not need a validation code for verification. One of the other important tools in this menu is the “Show Local Diagnosis Keys” which will verify that Local Diagnosis Keys have been generated (which can take up to an hour).


Focus of Primary Directives

Currently, Path Check is in Maintenance Mode for Heath Authorities. The main focuses QA needs to keep in mind during the day.

  1. Validate any current Release Candidate by following the Testing Checklist for the specific build

  2. Check for fixes implemented to the build that are ready for validation

  3. Locate and input bugs to the DB as directed or AdHoc

  4. Verify that Volunteer Management has all the resources they need to keep the volunteers at capacity



Expectations for Validation of Release Candidate

New Notes: See Testing & Verifying New Builds

OLD NOTES:

The Validation tests can be located HERE. The Verification General Test should be completed first, at the bottom it includes the End-To-End validation which requires AT LEAST TWO (2) phones and upwards of 12-24 hours for completion of the test. The End-to-End is also separated out for easy usage. There is also a separate page for the Interface Check validation steps and another page for the Upgrade Testing. I would recommend that the Interface Check be completed second, followed by the Upgrade Testing third, then the End-to-End Validation last. This is only a suggestion of best time management, your mileage may vary. Please see the page Export of Exposure Notifications Logs for post validation data retrieval from the phones. There is a page for tracking results HERE where the previous validations have been noted and the excel version of the verification tests can be downloaded for individual testing receipts.


 

Please continue to the Getting set up with iOS or Android (OLD) page to continue onboarding.