- The Day “Business as Usual” Broke: From COBOL to Java
- Are Test Cases an Asset That Never Dies—or a Growing Liability?
- The Reality of Japan’s “Quality Through Volume” Development
Wait—are there still more!? In a financial system project where test cases pile up like an avalanche, no one is laughing anymore.
■ Financial Systems Assume “A Lot of Test Cases”
In financial system development, having a large number of test cases is the norm.
Accounting, payments, balances, credit—any single mistake can lead to losses worth millions.
That’s why there’s a deeply rooted belief: “Too many tests is just enough.”
■ COBOL Assets = Decades of Accumulated Tests
This project aimed to fully replace a core system built in COBOL with Java.
In the COBOL world, test cases have been accumulated over decades.
They are not just checklists.
They represent past failures, exception handling, business quirks—
the very “pain history” of the system.
And most importantly,
those test cases do not disappear just because the programming language changes.
Business logic remains the same. In theory, they should be reusable.
■ But “Reusable” Doesn’t Mean “Ready to Use”
Reality isn’t that simple.
Moving from COBOL to Java eliminates some concerns entirely.
For example, memory management.
With Java’s garbage collection, many related tests become unnecessary.
Error handling also changes structurally, requiring redesign of test perspectives.
Yet, the business logic itself does not change.
So most test cases are still “largely reusable.”
■ Result: Nearly 10,000 Test Cases
After restructuring, about 10,000 test cases remained.
Is that a lot? Or not? No one says.
The only certainty:
it’s a volume with no visible end.
■ Testing Progresses Beautifully—Until It Doesn’t
At the beginning, everything goes smoothly.
Simple cases pass one after another.
It looks exactly like the textbook burn-down curve.
But that curve always stops at some point.
And then—it happens.
■ The Bottleneck Arrives Suddenly
At a certain point, testing stalls.
The causes are complex:
- Misinterpretation of specifications
- COBOL-specific behavior
- Java design philosophy
- Unexpected business exceptions
They intertwine, making resolution difficult.
■ Will Working Overnight Solve It?
Will pulling an all-nighter fix it?
No, it won’t.
The issue is not time—it’s structure.
What remains is a staring contest between test cases and source code.
Time passes, but answers don’t come.
■ When Leaders Gather, “Specifications” Change
When things get stuck, leaders are called in.
What happens isn’t simple bug fixing.
It’s redefining the business itself.
Not fixing code, but deciding:
“What is the correct behavior?”
■ Daily Progress Becomes Just Numbers
Every morning and evening, updates are shared.
“How many cases did we complete today?”
There is no story—only numbers.
Progress is measured in quantity, not emotion.
■ The Essence of Japanese Development
This is a classic “quality through quantity” model.
Risks are eliminated through exhaustive coverage.
Quality is built through accumulation and experience.
That’s why Japan’s financial systems are among the most stable in the world.
■ But There Is a Cost
It’s heavy.
Carrying unchangeable history,
while trying to adopt new technology.
That contradiction defines the field.
■ What Are Test Cases, Really?
At some point, you realize:
Test cases are not just validation items.
They are the history of a company,
records of failures,
and accumulations of fear.
That’s why they can’t be easily reduced.
That’s why they never end.
■ And Yet, Systems Move Forward
Beyond 10,000 test cases,
a new financial system quietly takes shape.
コメント
コメントを投稿