When engineers say a feature is finished, someone must check it really does what users need before real people depend on it. This is acceptance testing, often called user acceptance testing or UAT. Adverts for business analysts in Ghanaian banks, telecoms and manufacturers, and for associate product roles, often list testing before go live and release readiness as duties. Mistakes caught here are far cheaper than mistakes customers find.
What acceptance testing checks
Engineers test that their code works. Acceptance testing asks a different question: does this meet the requirements and work for real users in real conditions? You test against the acceptance criteria you wrote earlier.
Writing test cases
A test case is a small script:
- Steps: exactly what to do.
- Test data: which account, amount or phone to use.
- Expected result: what should happen, taken from the acceptance criteria.
- Actual result and pass or fail, filled in while testing.
A Google Sheet with these columns works well. Always include unhappy paths: wrong PIN, empty wallet, no network, very long names.
Testing in real conditions
Test in the staging environment first, using test accounts. Then think about how users really live: