Home/QA case studies/4 of 6
Allows users to register automatic debit schedules for recurring biller payments. Testing focused on time-based transaction logic, scheduling accuracy, and correct deduction behavior across different account statuses.
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 registering a schedule to running it without enough balance.
Scroll the table sideways to see every column.
| TC ID | Status | Test scenario | Test steps | Expected result | Actual result | Priority |
|---|---|---|---|---|---|---|
| TC-ADB-01 | PASS | Register autodebit for PLN billing |
| Autodebit registered; record saved in autodebit_schedule table with status ACTIVE | Autodebit registered and saved to DB correctly | High |
| TC-ADB-02 | FAIL | Autodebit execution on scheduled date |
| Deduction executed at correct time; balance reduced; transaction logged in Kibana | Deduction executed but at 30-minute delay from scheduled time | High |
| TC-ADB-03 | FAIL | Cancel active autodebit registration |
| Autodebit removed from UI; record in DB updated to status CANCELLED | Autodebit removed from UI but DB status remains ACTIVE | Medium |
| TC-ADB-04 | PASS | Autodebit execution with insufficient balance |
| Transaction fails; user receives insufficient balance notification | Transaction fails with correct notification sent to user | High |
Three sample bug reports, as written for the development team.
ExpectedExecution at exact scheduled time.
ActualExecution occurs 30 minutes after scheduled time based on Kibana event logs.
Priority: High
ExpectedStatus = CANCELLED in DB.
ActualStatus remains ACTIVE; risk of unintended future deduction.
Priority: Medium
ExpectedNavigate to Telkom autodebet detail page.
ActualNavigated to PLN detail page instead.
Priority: Medium
One query to validate the data, one to track the defects.
SELECT schedule_id, scheduled_time, executed_time, CAST((JULIANDAY(executed_time) - JULIANDAY(scheduled_time)) * 24 * 60 AS INTEGER) AS delay_minutes FROM autodebit_execution_log WHERE schedule_id = 'ADB-000123';
Used to quantify the execution delay reported in BUG-ADB-01, cross-checking the database timestamps against Kibana event logs and confirming a 30-minute delay from the scheduled deduction time.
project = "LIVIN" AND component = "Autodebit" AND issuetype = Bug AND status IN ("Open", "In Progress", "Reopened") ORDER BY priority DESC, created ASC
Lists open Autodebit-related defects such as execution delays (BUG-ADB-01) and status sync issues (BUG-ADB-02), ordered by priority for sprint planning.
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.