Annisa Nurul Islami

Home/QA case studies/5 of 6

Enhancement MTR (Mandiri Tabungan Rencana)

MTR is a flexible savings plan with automatic monthly deductions (IDR/USD, 1–20 year tenors, free life insurance). This project tested enhancements requiring regression testing to ensure existing functionality remained intact.

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.

Sample test cases

Four cases, including a regression check after deployment.

Scroll the table sideways to see every column.

TC IDStatusTest scenarioTest stepsExpected resultActual resultPriority
TC-MTR-01PASSCreate MTR in IDR with monthly setoran Rp 500.000
  1. Navigate to Tabungan Rencana
  2. Select IDR
  3. Set setoran Rp 500.000/month
  4. Set tenor 3 years
  5. Confirm
MTR created; record in DB with correct amount, currency, tenor, and ACTIVE statusMTR created and all fields saved correctly in databaseHigh
TC-MTR-02FAILCreate MTR in USD with monthly setoran USD 10
  1. Navigate to Tabungan Rencana
  2. Select USD
  3. Set setoran USD 10/month
  4. Confirm
MTR USD created; record saved with currency = USD and amount = 10MTR created with USD currency but amount saved as IDR equivalent in DBHigh
TC-MTR-03FAILMTR account display for frozen account status
  1. Set MTR account status to Frozen
  2. Navigate to MTR detail page
Page shows frozen account message; actions (top-up, cancel) are disabledPage shows frozen status but Top Up button remains active and tappableMedium
TC-MTR-04PASSRegression: existing MTR auto-debit still executes after enhancement deployment
  1. Verify pre-existing MTR auto-debit schedule
  2. Check execution after new build deployment
Pre-existing auto-debit continues to execute on schedule without interruptionPre-existing auto-debit executed correctly after enhancement deploymentHigh

Bugs found

Three sample bug reports, as written for the development team.

BUG-MTR-01Severity high

MTR USD amount saved as IDR equivalent value in database

Steps to reproduce

  1. Create MTR with USD 10 monthly setoran
  2. Query MTR record in DB

ExpectedAmount = 10, currency = USD.

ActualAmount = 160000 (IDR equivalent), currency = USD — data mismatch causes incorrect auto-debit.

Priority: High

BUG-MTR-02Severity medium

Top Up button active on frozen MTR account — not aligned with PO acceptance criteria

Steps to reproduce

  1. Set MTR account status = FROZEN
  2. Open MTR detail page
  3. Observe Top Up button state

ExpectedTop Up button disabled/hidden per PO requirement for frozen accounts.

ActualTop Up button remains enabled; tapping initiates transaction flow.

Priority: Medium

BUG-MTR-03Severity medium

MTR setoran history UI shows incorrect month label after enhancement

Steps to reproduce

  1. Open MTR setoran history after new build
  2. Check month labels on transaction list

ExpectedCurrent month label (e.g., July 2026).

ActualMonth label shifted by 1; shows June 2026 for July transactions.

Priority: Low

SQL and JQL

One query to validate the data, one to track the defects.

SQL · data validation (SQLite)
SELECT mtr_id, account_id, currency, amount, tenor_years, status
FROM mtr_accounts
WHERE mtr_id = 'MTR-000045';

Confirms BUG-MTR-01: the USD amount was stored as its IDR-equivalent value (160000) instead of the original amount (10), which would cause incorrect future auto-debit deductions.

JQL · bug tracking
project = "LIVIN"
AND component = "MTR"
AND issuetype = Bug
AND status IN ("Open", "In Progress", "Reopened")
ORDER BY priority DESC, created ASC

Tracks open defects for the MTR enhancement, prioritizing the currency conversion issue (BUG-MTR-01) ahead of lower-severity UI bugs.

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.