Oracle Fusion Cloud Testing
Oracle Fusion is the dominant ERP in NZ government (AoG panel). Learn to navigate its module architecture, test finance and HR workflows, and understand the three layers every change requires testing at.
1 The Hook
A large NZ government agency ran Oracle Fusion Financials. A new cost centre structure was activated mid-financial year — approved by the CFO, implemented by the Fusion team overnight. No testing was done because “it’s just a configuration change.”
The problem: the new cost centre hierarchy changed how the budget transfer rules evaluated department codes. Budget transfers that had previously routed and posted correctly now failed silently — they appeared to succeed in the UI but the underlying FBDI (File-Based Data Import) that fed the nightly batch did not recognise the new codes. Six months of management reports showed incorrect spend data by department. The budget holders had been making decisions on wrong numbers.
The testers had only tested the UI change — “the new cost centre appears in the dropdown.” Nobody had tested the FBDI import that consumed cost centre codes downstream, or the OTBI reports that displayed the results. That is the lesson: every Oracle Fusion change has three layers, and all three must be tested.
2 The Rule
Every Oracle Fusion change has three layers to test: (1) the UI workflow and approval routing, (2) the underlying flex fields, business rules, and configuration, and (3) the integration interfaces — FBDI imports, REST APIs, and ESS scheduled jobs. Miss any layer and you have a gap that will surface in production.
3 The Analogy
Oracle Fusion is like an iceberg.
The UI is 20% above the water — visible, clickable, demonstrable in demos. Below the surface: ESS (Enterprise Scheduler Service) jobs that run nightly, FBDI file imports that load bulk data, OTBI reports that aggregate and display results, REST APIs that talk to payroll and HR systems, and the business rule engine that enforces delegation limits, account codes, and approval hierarchies.
Most testers test the tip. ERP-qualified testers test the iceberg. A UAT sign-off based only on UI walkthroughs is a sign-off on 20% of the system.
4 Watch Me Do It
Here is a complete test case for Oracle Fusion Financials — testing a journal entry through the full approval and posting cycle, including the OTBI report output:
Scenario: Manual journal entry — approval routing and posting verification
Steps:
1. Navigate to Journals → Create Journal
2. Enter: Ledger = NZ Primary Ledger, Currency = NZD, Category = Manual
3. Enter debit line: Account 1234.000.0001 (Dept Cost Centre) $5,000
4. Enter credit line: Account 2345.000.0000 (Control Account) $5,000
5. Verify balance = $0.00 before submit (journal must balance)
6. Submit for approval → verify workflow routes to correct approver
(check approval rule: amount > $2,000 = Finance Manager required)
7. Log in as Finance Manager → verify journal in worklist
8. Approve → verify status changes to “Posted”
9. Run OTBI Trial Balance report for the period → verify both lines appear
10. Verify account codes in Trial Balance match the entered values exactly
Expected: Journal balances, routes to correct approver, posts, appears in OTBI.
Failure modes to check: unbalanced journal rejected; wrong approver routed;
posted journal not in OTBI; wrong account code in report output.
5 Decision Tool
Oracle Fusion offers multiple testing tools. Choosing the right one depends on what you are testing and the project stage:
| Tool | Best for | Limitations |
|---|---|---|
| Oracle Test Manager (OTM) | Structured test case management, linking test cases to requirements, defect tracking within the Oracle ecosystem | Requires Oracle licencing; limited to test management, not execution automation |
| Selenium / Playwright | UI regression automation for stable Fusion workflows; end-to-end smoke tests after quarterly updates | Oracle Fusion UI is dynamic; selectors break on quarterly cloud updates; maintenance overhead is high |
| Manual testing | Configuration testing, FBDI validation, first-pass SIT, UAT facilitation, exploratory testing around new configuration | Not scalable for regression; cannot cover FBDI batch processing volumes automatically |
| FBDI template testing | Bulk data load validation — upload a test file, verify ESS job output, check error reports | Requires correct file format; column order is version-sensitive; test with realistic row counts |
6 Common Mistakes
🚫 Not testing FBDI file format headers after a quarterly Oracle update
Why it happens: FBDI templates look the same across releases and teams assume they are stable.
The fix: Oracle occasionally changes column order or adds mandatory columns in quarterly cloud updates. Always download the current FBDI template from the Oracle Help Centre after every update, compare it to the one your integration uses, and run a test load before the update goes to production. A column order mismatch causes silent data corruption, not an obvious error.
🚫 Testing only the happy path through an approval workflow
Why it happens: The approval path is what the demo showed, and it passes, so the tester moves on.
The fix: Approval workflows have multiple paths: approve, reject, send back for correction, escalate on timeout, and withdraw. Test all of them. A rejection path that fails means approvers cannot send work back to submitters, which blocks the entire process in production. Timeouts and escalations are commonly untested and commonly broken.
🚫 Forgetting to test ESS scheduled jobs that run overnight
Why it happens: ESS jobs are invisible during the business day and not part of the UI walkthrough.
The fix: Many Oracle Fusion processes depend on ESS jobs: GL posting, period close sweeps, intercompany netting, and report generation. Run these jobs manually in the test environment and verify their output. If an ESS job fails silently in production, the consequences appear hours later when users find stale data or unposted transactions — hard to diagnose, expensive to fix.
7 Now You Try
Paste or edit the prompt below, then click Run to get a real AI response.
8 Self-Check
Click each question to reveal the answer.
Q1: What are the three layers of Oracle Fusion that must be tested on every change?
1. The UI workflow and approval routing — what users see and interact with. 2. The underlying flex fields, business rules, and configuration — the cost centre codes, delegation limits, account rules that drive the process. 3. The integration interfaces — FBDI file imports, REST APIs connecting to external systems, and ESS scheduled jobs that run the overnight processing. A test suite that only covers the UI is covering roughly 20% of the system.
Q2: What is FBDI and why does it matter to Oracle Fusion testers?
FBDI stands for File-Based Data Import. It is Oracle Fusion’s bulk data loading mechanism — a set of standardised spreadsheet templates that the system imports via an ESS job. FBDI matters to testers because it is how most integration data enters Oracle Fusion (general ledger journals, supplier invoices, asset additions), and it is version-sensitive: Oracle can change column order or add mandatory columns in quarterly updates. A tester who does not validate FBDI files will miss the entire class of bulk-data defects that only appear when large datasets are processed.
Q3: How should you approach regression testing when Oracle does quarterly cloud updates?
Quarterly updates are mandatory in Oracle Fusion Cloud — you cannot opt out. The approach is: (1) maintain a core regression pack of smoke tests covering the highest-risk business processes; (2) run this pack in the test environment when Oracle previews the update, before it reaches production; (3) download updated FBDI templates and compare them to your current integration templates; (4) check Oracle’s release notes for any changes in the modules you use; (5) prioritise testing any workflow or configuration that Oracle has noted as changed. Selenium/Playwright automation helps but requires maintenance after each update because Oracle’s UI can shift.
9 Interview Prep
Real questions asked in NZ QA interviews for Oracle Fusion roles. Read the model answers, then practise your own version.
“How do you approach regression testing when Oracle does quarterly cloud updates?”
Oracle Fusion Cloud updates quarterly and you cannot opt out, so regression is a recurring programme activity, not a one-off. I maintain a regression pack of critical business process smoke tests — typically 30 to 50 test cases covering the highest-risk workflows. When Oracle previews an update I run this pack in the preview environment before the update reaches production. I also check the release notes specifically for changes to modules we use, download updated FBDI templates and diff them against the ones our integrations use, and test any workflow Oracle has flagged as changed. The key is making regression a planned event with a defined scope, not a panic after go-live.
“What is FBDI and why does it matter to testers?”
FBDI is Oracle Fusion’s File-Based Data Import mechanism — spreadsheet templates that load bulk data via ESS jobs. It matters to testers for three reasons. First, it is how most integration data enters Oracle, so if the FBDI is broken, nothing downstream works correctly. Second, it is version-sensitive — Oracle changes column layouts between releases, which can break an integration silently if the integration team does not notice. Third, FBDI errors often appear in an error report rather than as an on-screen failure, so a tester who only checks the UI will miss them. I always include an FBDI test in any integration test plan: upload a test file, trigger the ESS job, check the output and the error report, and verify the imported data looks correct in the application.