Home/QA case studies/3 of 6
Bundled feature integrating e-Money top-up with AXA Mandiri insurance, allowing customers to reload e-Money balance and access insurance benefits in a single flow. Requires validation across two external service providers.
4 sample test cases2 pass2 fail3 bugs found
Note: all test cases and bug reports in this portfolio are illustrative samples reconstructed from memory after leaving Bank Mandiri. Original documents were stored in Jira, accessible only via the internal Bank Mandiri network. Feature names, flows, and defect types reflect actual work performed; sensitive internal data has been anonymized.
Four cases across the top-up flow and the AXA endpoint.
Scroll the table sideways to see every column.
| TC ID | Status | Test scenario | Test steps | Expected result | Actual result | Priority |
|---|---|---|---|---|---|---|
| TC-EMX-01 | PASS | Top-up e-Money Rp 100.000 with AXA insurance bundled |
| e-Money balance +Rp 100.000; AXA insurance activated; both records saved in DB | e-Money balance updated correctly; AXA insurance record saved successfully | High |
| TC-EMX-02 | FAIL | Data mismatch between e-Money balance on UI and database |
| UI balance matches database value exactly | UI shows Rp 200.000 increase but DB only updated by Rp 100.000 | High |
| TC-EMX-03 | PASS | Top-up with restricted account status |
| Error: account restricted, transaction blocked with clear message | Error message displayed correctly | High |
| TC-EMX-04 | FAIL | AXA insurance endpoint returns wrong error code on timeout |
| API returns 504 Gateway Timeout with appropriate error message | API returns 200 OK with null insurance data instead of timeout error | High |
Three sample bug reports, as written for the development team.
ExpectedDB balance matches UI exactly.
ActualDB balance difference of Rp 100.000 from UI displayed amount.
Priority: High
Expected504 with TIMEOUT error code.
Actual200 OK with null insurance_data field, causing silent failure.
Priority: High
ExpectedAXA bundle section fully visible and aligned.
ActualAXA bundle CTA button partially cut off below screen fold.
Priority: Low
One query to validate the data, one to track the defects.
SELECT account_id, balance, updated_at FROM e_money_balance WHERE account_id = '1023456789' ORDER BY updated_at DESC LIMIT 1;
Used to confirm BUG-EMX-01: the database balance reflected only a Rp 100.000 increase while the app UI displayed a Rp 200.000 increase after top-up, revealing a frontend-backend data mismatch.
project = "LIVIN" AND component = "e-Money AXA" AND issuetype = Bug AND status IN ("Open", "In Progress", "Reopened") ORDER BY priority DESC, created ASC
Surfaces open defects for the e-Money/AXA bundling feature, useful for coordinating fixes that span both internal systems and AXA's external API.
About the SQL. The query is an illustrative example reconstructed to show the type of database validation performed during testing. Table and column names have been generalized and anonymized and do not reflect the actual production schema. It uses SQLite syntax as a lightweight, portable reference; the same logic applies on MySQL or PostgreSQL with minor syntax adjustments.
About the JQL. It uses Jira's real query language and reflects the kind of filter commonly used for defect tracking. The project key ("LIVIN") and component name are illustrative. JQL filters and sorts issues; for counts by status or component, the filter is combined with Jira's "Group By" option or a dashboard gadget.