Home/QA case studies/1 of 6
A feature enabling OVO account linkage and top-up from Livin' by Mandiri, built on the SNAP (Standar Nasional Open API Pembayaran) standard by Bank Indonesia. Technically complex due to strict BI-standard API compliance and dual-system integration.
5 sample test cases2 pass3 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.
Five cases, from linking an OVO account to unlinking it.
Scroll the table sideways to see every column.
| TC ID | Status | Test scenario | Test steps | Expected result | Actual result | Priority |
|---|---|---|---|---|---|---|
| TC-OVO-01 | PASS | OVO account linking with active Mandiri account |
| OVO account successfully linked and displayed on e-Wallet dashboard | OVO account linked successfully | High |
| TC-OVO-02 | PASS | OVO top-up with valid amount (Rp 50.000) |
| OVO balance increases by Rp 50.000; transaction recorded in history | OVO balance increases by Rp 50.000; transaction recorded in history | High |
| TC-OVO-03 | FAIL | OVO top-up with frozen Mandiri account as source |
| Error message displayed: account frozen, transaction cannot proceed | Transaction processed without error; account balance deducted despite frozen status | High |
| TC-OVO-04 | FAIL | API error response for invalid OVO phone number |
| API returns 400 Bad Request with error code INVALID_OVO_ACCOUNT | API returns 200 OK with empty response body instead of proper error code | High |
| TC-OVO-05 | FAIL | OVO unlink from e-Wallet |
| OVO account removed from e-Wallet; record deleted from database | OVO account removed from UI but record still exists in database | Medium |
Three sample bug reports, as written for the development team.
ExpectedBlocked with frozen account error.
ActualTransaction deducted balance despite frozen status.
Priority: High
Expected400 Bad Request with INVALID_OVO_ACCOUNT error code.
Actual200 OK with empty response body.
Priority: High
ExpectedRecord deleted from DB.
ActualRecord remains with status ACTIVE in linkage table.
Priority: Medium
One query to validate the data, one to track the defects.
SELECT a.account_id, a.status AS account_status, o.status AS ovo_linkage_status FROM accounts a JOIN ovo_linkage o ON a.account_id = o.account_id WHERE a.status = 'FROZEN' AND o.status = 'ACTIVE';
Used to confirm the root cause of BUG-OVO-01: checking whether frozen accounts still had an active OVO linkage that should have blocked the top-up transaction.
project = "LIVIN" AND component = "OVO Linkage" AND issuetype = Bug AND status IN ("Open", "In Progress", "Reopened") ORDER BY priority DESC, created ASC
Lists all open defects tagged under the OVO Linkage component, such as BUG-OVO-01 and BUG-OVO-03, for focused tracking during the sprint.
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.