Peer-to-peer payment app testing checklist

Download the checklistMarkdownCSVBrief (Markdown)

1. 1.release smoke testsDone when: On every store build, a tester installs the app fresh, links a test card, sends a payment to a second test user and sees it arrive once.Risks: store-rejection. Tool class: mobile automation. Usually run by: QA engineer.
2. 2.end-to-end functional testsDone when: A payment held for review shows as pending to the recipient with the cash-out button disabled until the review clears, and a password, email or phone change or a login on a new device sends an alert to the previous contact details.Risks: money-loss, fraud-abuse. Tool class: mobile automation. Usually run by: QA engineer.
3. 3.security scanningDone when: Each release build is scanned and no open high finding remains on login, password reset, device binding or the endpoints that return private payments.Risks: fraud-abuse, data-breach. Tool class: DAST scanner. Usually run by: security specialist.
4. 4.penetration testingDone when: An external tester cannot take over a test account through password reset, SIM swap simulation or session reuse, and cannot read another user's private payments.Risks: fraud-abuse, data-breach. Tool class: proxy. Usually run by: security specialist.
5. 5.compliance checksDone when: A test unauthorised-send claim opens an error investigation with a provisional credit decision and a written result, without routing the user to their card issuer.Risks: regulatory-penalty, money-loss. Tool class: test management. Usually run by: product manager.
6. 6.exploratory testingDone when: A tester acting as a scammer tries fake support contacts, payment requests with misleading notes and refund tricks, and each working path is logged as a defect.Risks: fraud-abuse. Tool class: test management. Usually run by: QA engineer.
7. 7.data integrity and migration testingDone when: After each statement from the app's bank, the sum of user balances, pending sends and cash-outs equals the funds held there; a run that finds a difference lists it by user.Risks: money-loss. Tool class: data validation. Usually run by: QA engineer.
8. 8.regression suiteDone when: After each release, a payment marked private by either party never appears on the public or friends feed of a third test user.Risks: data-breach. Tool class: mobile automation. Usually run by: QA engineer.