What is AHI's QA process?
AHI have a Quality Assurance team to help verify that AHI technology is integrated appropriately. This is help our clients get the most out of the AHI scan technology and avoid common mistakes.
What We Check
The AHI quality assurance team will check off the following:
- User Interface: Where pertaining to activities directly affecting the Scan operations and outputs, the implemented UI will be compared to the designs provided by the client to ensure implementation matches designs.
- Functional Checks: The functionality of the individual Scans is verified for consistency. Including the app displaying expected results, and any derived results.
- Usability/User Experience Checks: The flow of the app directly leading up to the creation of a scan, the act of performing a scan, and any part of the app either displaying results or displaying derived results will be checked to ensure it makes sense for users. And that the first and returning user experiences are acceptable.
What We Don't Check
The AHI quality assurance team is not responsible for the general testing of client's apps. However, if the team does discover something in your app, as a courtesy we will inform the client.
How We Check
AHI's quality assurance team will execute several test scenarios against the client's app.
Minimum Acceptance Criteria
- The implemented UI matches designs supplied.
- The UI contains no unreadable text.
- The app contains no offensive language.
- Users of the app can create a new account.
- Users of the app can perform Scan(s).
- Any in-app purchases pertaining to the ability to perform Scans are functioning.
- When a user is either unsubscribed or hasn't purchased a Scan, they are unable to perform a Scan.
- Expected results are being returned from the Scans, any derived results are being calculated correctly.
- The appropriate billing events are being sent to AHI's billing database.
What happens if a defect is discovered?
Any defects discovered in the activities directly pertaining to the operation of performing a Scan or Scans will be logged, prioritized and categorized.
Defects will be prioritized by their likelihood to occur, and the severity of their impact on a user performing a Scan or Scans.
Defects will be categorized into two categories, blockers and potential issues for consideration.
Blockers will need to be completed prior to the app being signed off by AHI, an example blocker is the user being unable to perform one of the provided Scans or the Scan not functioning correctly. Considerations are generally graphical inconsistencies in the app that the client might want to action prior to go live, or potentially in a different version of the app. An example of a consideration is a color in one of the Scan capture processes not matching the colors used throughout the app.
Once all blockers have been resolved, and any of the considerations determined to be completed for release have been verified, the AHI quality assurance team will sign the app off, and it will be considered go-live ready.