Bank Victim Compensation Feature
Context
Independently developed a new feature on a legacy Japanese banking system. 5-person team, each responsible for a separate module. I owned my feature end-to-end: frontend, backend, and database — on Apache Struts and Oracle DB, a stack I had no prior experience with.
The Testing Methodology
The real contribution wasn't the code — it was the testing framework. In financial systems, confusing a business error with a system error can cause real damage. I formalized the distinction:
Business Errors
- Amount exceeds limit
- Recipient info incomplete
- Status disallows operation
Action: Action: Block, return clear user message.
System Errors
- DB connection failure
- Write timeout
- Transaction rollback
Action: Action: Log, rollback, notify admin.
Test Case → Design Doc Mapping
Every test case was a 1:1 mapping to a design document specification. Normal paths, business error paths, and system error paths were all covered. I reviewed the mapping with the client to confirm alignment before testing began. This ensured no ambiguity about what "correct behavior" meant.
Legacy System Development
I had never touched Apache Struts before this project. Learned by reading existing code, then matched the naming, implementation, and commenting conventions so my code was indistinguishable from the original system. This is a skill I carried into every subsequent project: absorb conventions, then contribute as if you were always there.