Testing & UAT
10.1 The test environment
- Use the test base URL and test credentials from InnBucks.
- Pay codes with the test customer app (Android), registered with a Zimbabwean number and funded by InnBucks (3.3).
- Deep links must use the test scheme
zw.co.innbucksnova.test://(5.3). - Keep a list of the InnBucks references (
code,authNumber,stan) of every test: the UAT form asks for them.
10.2 Test cases
InnBucks’ UAT sign-off form has these test cases. Run each one and record the result as Pass, Pass with exception, Fail or Not tested / not applicable, with the transaction or request reference.
| # | Test case | Steps | Expected result |
|---|---|---|---|
| UAT-1 | Authentication | Send a login request with the required data and format | A success response with an access token |
| UAT-2 | Generate payment code | Generate a PAYMENT code; display the code and QR code; pay it with the app or USSD |
A success response with the code and QR code; the customer can complete payment with the code |
| UAT-3 | Generate withdrawal code | Generate a WITHDRAWAL code; display the code and QR code; claim it with the app or USSD |
A success response with the code and QR code; the customer can complete the withdrawal with the code |
| UAT-4 | Code inquiry | Request the latest status of a code | A success response with the code’s latest status and its time to live |
| UAT-5 | Code mini statement | Request the recent code-based transactions | A success response listing recent code-based transactions (14.3) |
Mark the cases that don’t apply to you (for example UAT-3 if you are not an agent) as Not tested / not applicable. Before signing off, also test the cases InnBucks will see in your video and your logs:
| # | Scenario | Expected behaviour in your app |
|---|---|---|
| T-1 | Customer pays within 10 minutes | Status Claimed (or Paid); order fulfilled once |
| T-2 | Customer never pays | Status Expired or Timed Out after 10 minutes; order not fulfilled; new code offered |
| T-3 | Token expires mid-session | Automatic re-login; the request succeeds |
| T-4 | Customer asks for a new code, then pays the old one | Old code still checked and matched to the order |
| T-5 | Status checks | One inquiry per code every 30 seconds, no faster |
| T-6 | Deep link on mobile | Opens the test app on the payment screen |
| T-7 | Agent: deposit, lost response, deposit inquiry, reversal | Inquiry finds the deposit; reversal returns 00 |
| T-8 | Bank change above US$5 | Rejected by your app before calling InnBucks |
10.3 Record the customer journey video
Record a short video, 1 to 2 minutes at most, of the customer journey in your real app or website. Show:
- how the customer chooses InnBucks and sees the code and QR code (and the deep link on mobile)
- a successful payment, and how your app shows it
- a failed or expired payment, and how your app shows it
- each transaction type you enabled (payment codes, withdrawal codes, and so on)
InnBucks uses the video to check branding consistency and a smooth journey for customers.
10.4 Submit for sign-off
- Complete and sign the UAT sign-off form: your merchant or agent name, contact name, cell number and email, each test case result with its InnBucks reference, and the sign-off by a named person with their designation.
- Email the signed form and the video to merchants@innbucks.co.zw.
- InnBucks reviews its transaction logs against your references, and countersigns.
After sign-off, any change to the approved customer journey must be communicated to and approved by InnBucks before you release it.
This page is generated from section 10 of the README in README.md. Spotted something wrong? Open an issue.