Home/QA case studies/6 of 6
Two-phase feature: the customer submits a debit/ATM card request digitally via Livin', then collects the physical card at a designated branch. Integrates mobile banking with Bank Mandiri's branch card issuance system.
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, from submitting the request to tracking its status.
Scroll the table sideways to see every column.
| TC ID | Status | Test scenario | Test steps | Expected result | Actual result | Priority |
|---|---|---|---|---|---|---|
| TC-CRD-01 | PASS | Submit card request for physical card pickup at branch |
| Request submitted; record created in DB with status PENDING; confirmation screen displayed | Request submitted and record created correctly in database | High |
| TC-CRD-02 | FAIL | Card request submission with restricted account |
| Error displayed: account restricted, card request cannot be submitted | System shows generic error page with no specific restricted account messaging | Medium |
| TC-CRD-03 | PASS | API response for card request submission |
| POST /card-request returns 201 Created with request_id in response body | API returns 201 Created with correct request_id | High |
| TC-CRD-04 | FAIL | Card request status tracking after submission |
| Status shows PENDING with estimated pickup date displayed | Status page shows PENDING but estimated pickup date field is blank | Medium |
Three sample bug reports, as written for the development team.
ExpectedMessage 'Akun Anda dibatasi, tidak dapat mengajukan kartu'.
ActualGeneric error page with no account-specific guidance.
Priority: Medium
ExpectedEstimated pickup date visible (e.g., '3-5 hari kerja').
ActualDate field blank; feature does not meet PO acceptance criteria.
Priority: Medium
ExpectedAll UI elements aligned correctly.
ActualBranch address text overlaps with map widget on confirmation screen.
Priority: Low
One query to validate the data, one to track the defects.
SELECT request_id, account_id, status, estimated_pickup_date, submitted_at FROM card_requests WHERE request_id = 'CRD-000789';
Confirms BUG-CRD-02: the estimated_pickup_date field returned NULL instead of a valid date, meaning the status tracking page could not meet the PO's acceptance criteria.
project = "LIVIN" AND component = "Card Request" AND issuetype = Bug AND status IN ("Open", "In Progress", "Reopened") ORDER BY priority DESC, created ASC
Retrieves open defects for the Card Request & Branch Pickup feature, helping track UI and status-tracking issues before release.
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.