Home/QA case studies/2 of 6
Digital savings account for teenagers aged 12–17, connected to a parent's Livin' account. Features dual-persona flows requiring rigorous testing of parent-child account interactions and parental control mechanisms.
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 parent and the teen account.
Scroll the table sideways to see every column.
| TC ID | Status | Test scenario | Test steps | Expected result | Actual result | Priority |
|---|---|---|---|---|---|---|
| TC-NXG-01 | PASS | Parent creates Next-G account for teen |
| Teen account created and linked to parent account; record saved in DB | Teen account created and linked successfully | High |
| TC-NXG-02 | FAIL | Parent sets spending limit for teen account |
| Spending limit saved and enforced; teen cannot transact above limit | Spending limit displayed on UI but not saved to database; limit not enforced | High |
| TC-NXG-03 | FAIL | Result screen when teen account is restricted |
| Screen shows restricted account message with guidance to contact parent | Screen shows generic error page with no relevant information | Medium |
| TC-NXG-04 | PASS | Parent monitors teen transaction history |
| Full teen transaction history displayed with date, amount, merchant | Transaction history displayed correctly | Medium |
Three sample bug reports, as written for the development team.
ExpectedRecord inserted/updated in DB with new limit.
ActualDB record unchanged; limit only visible on UI until page refresh.
Priority: High
ExpectedScreen displays 'Akun dibatasi, hubungi orang tua'.
ActualGeneric error page with no account-specific messaging.
Priority: Medium
ExpectedNavigate to Next-G transaction detail page.
ActualRedirected to main Tabungan page instead of Next-G detail.
Priority: Medium
One query to validate the data, one to track the defects.
SELECT teen_account_id, daily_limit, updated_at FROM spending_limit WHERE teen_account_id = 'TEEN-000456';
Expected: daily_limit = 500000 after being set by the parent. Actual (defect, ref: BUG-NXG-01): the record remained unchanged in the database, confirming the spending limit was not persisted despite appearing saved on the UI.
project = "LIVIN" AND component = "Next-G" AND issuetype = Bug AND status IN ("Open", "In Progress", "Reopened") ORDER BY priority DESC, created ASC
Retrieves open defects under the Next-G component, including high-priority issues such as BUG-NXG-01 affecting parental control enforcement.
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.