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 Voluntary Member Managers Stella Nelson and Jonathon Wright of Vivit Worldwide (LINK) both of whom are valued contributors and incredibly knowledgeable about Quality Assurance. The Volunteer force is dependent on their expertise in both management and technology. To note: They are on Slack and in the located in UK on GMT. Please see Arthur Gibson for details.
There is a high-end security team that is run by Alexander Chaveriat of 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, but that may change (or may have already been changed). However, to note, the fixed issues will appear in the ON BUILD READY FOR QA TEST lane when they are ready for validation.
TO NOTE: Some of the documents here in the confluence area may be outdated. I’m going to break the fourth wall here to try to assist this information transfer because I tried to create an intro and an overall view of the product to help onboard any internal QA as well as update some pages of the documentation. However, some pages referenced were previously written by QA such as Diarmid Mackenzie and Dave Runkle and therefore may have gone out-of-date. 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 Internal QA - Getting set up with iOS or Android, 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 works towards a *weekly Sprint for Release Candidate for Heath Authorities. This may have changed, however, at the time of writing here are the main focuses QA needs to keep in mind during the day.
Validate the current Release Candidate by following the (Validation Steps) if the build is ready
Verify that Volunteer Management has all the resources they need to keep the volunteers at capacity
Check for fixes implemented to the build that are ready for validation
Locate and input bugs to the DB as directed or AdHoc
*team format is to have a build ready to test by Monday, validated on Tuesday and given a greenlight/redlight by Wednesday if possible. At the time of writing the Sprint Review occurs on Thursday, and the next weeks build is kicked off on Friday.
Expectations for Validation of Release Candidate
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 Internal QA - Getting set up with iOS or Android page to continue onboarding.