Testing & QA Guide
Testing and Quality Assurance for OkHi in your app
Quality Assurance for an OkHi integration involves testing and verifying that the integration works as expected and meets the required quality standards. The integration may vary depending on your specific use case and requirements, however, there are general guidelines on how to test if your implementation is operating correctly.
How verification works
The most common mistake that we see teams make is not clearly understanding how verification differs from collection and validation. In our implementation, address creation is when the user creates their address via the web view screens that we provide. This then registers a geofence on the mobile operating system which periodically sends transit data (see transit data types) to our servers. Our AI models then use that data to create a profile of how much time the user spends inside the geofence and will determine their status.
The speed of our verification process depends significantly on the amount and quality of the transit data that we get sent from the device. There is no single pattern that we look for and are actively filtering out potential fraud or false positives. Even with the best data, we wait at least 36 hours before being confident enough to verify an address and the longest we will keep trying for is 8 days.
Our system is designed to confidently determine where a normal user lives and moves with their device. This can make it hard to simulate in a test without 'normal' behaviour.
Types of transit data
We combine multiple different types of transit data in our verification process. These include user activity as well as background geofence checks that happen periodically. Over the years we've combined multiple different methods of collection to ensure that we get a robust feed of transit data continuously through the verification process to ensure the most accurate results. This has been intentionally balanced to ensure that we're still using a minimal amount of battery and data from the device.
Testing Stages
There are 3 parts to testing if OkHi has been integrated correctly:
Step 1: Creation
This starts with Onboarding users about permissions and expectations through the various steps in creating an address. Note that there is some branching logic about using a previous address (from our address book) or if you're at the address currently. Typically the priming screens are done by your developers (see live examples) and the actual location permission prompts are done by our web views behaviour. It's worth adding that 'permission settings' include location permissions as well as optimisations on low-end Android phones which significantly throttle background services & apps.
Creating an address takes 3 steps, first to drop the pin on the map, second is an optional step to add a street view image (your developers may have opted out of this step), and third to capture the text address description. Note that for testing purposes, where the GPS pin is dropped needs to be the most accurate as that is what we use for our geofence. You can intentionally drop the pin in a location where you will not be at to test a failed verification.
After the address is created, it should show up in your address book for subsequent tests. You can create up to 20 locations on a single device. After that, you will need to delete the app, clear all data and reinstall a fresh version to continue testing.
Step 2: Verification
Some of our code libraries will automatically start verification, but it is possible that your developers have modified these calls or not initiated them. In that case, you will have an address created but no verification:started. A created address will show up in your address book in the creation stage or by logging into okhi.me. If verification has started it will show up in the OkHi Customer dashboard.
There is very little that you can do to influence the verification process (by design) other than to ensure that there are enough transit data points coming through. (See the Guidelines below for more info.)
Our system should also trigger a message to the user (via email, SMS or WhatsApp depending on implementation preferences) when a new user has started verification for the first time.
OkHi.me
Any end user can log into www.okhi.me (with an OTP SMS authentication) to see their address book and status. This can be a handy tool for testing to check what the status is in our system for multiple test addresses. This is also where users can opt out of data collection and tracking for us to stay compliant with data protection and privacy laws.
Step 3: Status
There is a status page (a full example can be found in the Integration Best Practices document) that should be visible in your app depending on where your developers have implemented it to share the status of an active address verification with the user.
The status of any pending or past verification is also available in the OkHi Customer dashboard.
verified
We have enough data to confidently say that the user stays at the address.
not_at_address
This means that we are getting sufficient transit data sent through, but that the user has not been at the address enough to verify them or they are not there at all. This is most common when people drop the pin at a location where they do not stay during the verification period.
unknown
This status means that our system did not receive enough data in order to be able to make a decision. See this guide on How to reduce Unknowns for more information.
General guidelines & tips
Here are some general tips and guides that increase the chances of a speedy verification. Note that these are general pointers and have various exceptions. These are not exact instructions as the models factor in many data points and patterns, specifically optimised to discount abnormal or unusual behaviour. (And location testing behavioural patterns typically look very different to the real-world behaviour of users.)
It helps to send multiple transit data events for a particular address in a 48-hour period. You may need more, or succeed with less depending on how accurately your behaviour mimics a real user.
If your test device stays in the office then you are likely to fail verification as our services will see it as fraud. (There are exceptions to this.) Taking it to lunch to trigger geofence enters and exits create more realistic data.
If there isn't much movement with the test device, then it is good to open the test app at least once an hour during the testing period to trigger more data being sent.
Our services are biased towards a normal user's routine, so it's best to keep the test device on you during the verification period so that you mimic a real user's movements. Leaving a test device in a views behaviour office testing environment will unlikely get you verified.
Leaving the app open will not send additional data.
GPS accuracy can vary a lot, particularly with older phones, when you're on low battery, or deep inside a building with poor reception. This can cause your device location to jump around a lot and means that you need to walk a few hundred meters away to confidently fire geofence events. (we aggregate data points to improve accuracy on the backend later.)
OS-level geofence data can have delays depending on OS, so leaving an area for only a very short period can sometimes not register as an enter or exit.
🤔
Still got questions?
read our FAQs >
📋
Looking for a testing template?
View testing boilerplate >
Our team is here to help.
We've done this a lot and are always on hand to help you troubleshoot to check the implementation. Send us a test build or ask us to check the actual data payloads for a test device if you need help troubleshooting.
Get in touch or join our Integrations Slack community for support.
Last updated