NFT (Non-Functional Testing) Planning for Oracle Fusion ERP Implementations

When organizations implement Oracle Fusion ERP, the bulk of testing attention typically goes to functional validation — does the payroll run calculate correctly, does the purchase order approval workflow route to the right approver, does the invoice match the goods receipt? These are critical questions. But they are only half the picture.

Non-Functional Testing (NFT) answers a different set of equally critical questions: How fast does the payroll run when 5,000 employees are processed simultaneously? What happens to the system when 300 concurrent users hit the financial close at month-end? Does the system recover gracefully if the primary database node fails?

In Oracle Fusion ERP implementations — whether cloud (SaaS), on-premise, or hybrid — NFT is frequently underplanned, underfunded, and executed too late in the project lifecycle to be actionable. This guide provides a comprehensive NFT planning framework specifically designed for Oracle Fusion ERP projects, from test strategy definition through to sign-off criteria.

This article is the third in our Oracle Fusion performance testing series. If you haven’t read the earlier pieces, we recommend starting with Using Apache JMeter for Oracle Fusion ERP Performance Testing: Concepts and Strategy and Oracle Fusion REST API Testing with JMeter for the technical execution context that complements this planning guide.

Table of Contents

1. What Is Non-Functional Testing in an ERP Context
2. NFT Categories for Oracle Fusion ERP
3. NFT Planning Framework
4. Defining NFT Scope by Oracle Fusion Module
5. Workload Modeling for Oracle Fusion
6. NFT Environment Strategy
7. Test Data Strategy for NFT
8. NFT Execution Phases and Timeline
9. Entry and Exit Criteria
10. Roles and Responsibilities
11. NFT Risks and Mitigations
12. Reporting and Sign-Off
13. Summary

1. What Is Non-Functional Testing in an ERP Context

Non-Functional Testing covers all testing activities that validate how a system performs its functions — as opposed to whether it performs them correctly. In standard software testing, NFT encompasses performance, security, reliability, usability, scalability, and maintainability testing.

For Oracle Fusion ERP implementations, NFT takes on a specific meaning shaped by the nature of enterprise systems:

Performance is not just about speed — it is about maintaining acceptable response times under the concurrent load of an entire organization’s workforce operating simultaneously during peak business periods.

Security in Oracle Fusion context means validating that the implemented security model — role-based access control, data security policies, segregation of duties — is correctly enforced and cannot be bypassed, in addition to traditional vulnerability assessment.

Availability and DR validates that the system meets its uptime commitments and that the Disaster Recovery plan actually works — that failover completes within the agreed RTO (Recovery Time Objective) and that data loss does not exceed the agreed RPO (Recovery Point Objective).

Usability ensures that the implemented Oracle Fusion configuration is navigable and operable by real users under realistic conditions — particularly important for organizations migrating from legacy ERP systems where users have deeply ingrained workflows.

Integration performance validates that the data flows between Oracle Fusion modules and external systems (banks, HRIS, logistics platforms, legacy systems) can sustain production transaction volumes without bottlenecks or data loss.

NFT is not a single test — it is a coordinated program of activities that must be planned, resourced, and executed with the same rigor as functional System Integration Testing (SIT) or User Acceptance Testing (UAT).

2. NFT Categories for Oracle Fusion ERP

A complete NFT plan for Oracle Fusion ERP covers six testing categories. Each answers a distinct question about system readiness.

Performance Testing

Question: Does the system respond within acceptable time limits under expected load?

Validates end-to-end response times for critical business transactions when the system is under normal and peak concurrent user load. Covers both UI interactions and REST API calls.

Load & Stress Testing

Question: What is the system’s capacity ceiling, and how does it behave when that ceiling is breached?

Load testing validates behavior at expected peak load. Stress testing deliberately exceeds that peak to identify the breaking point and observe failure behavior. Together they define the system’s operational envelope.

Security Testing

Question: Does the implemented security model protect business data and prevent unauthorized access?

Covers Oracle Fusion role-based access control (RBAC) validation, Segregation of Duties (SoD) conflict testing, data security policy enforcement, network security (TLS configuration, exposed ports), and vulnerability scanning of custom configurations and integrations.

Availability & Disaster Recovery (DR) Testing

Question: Does the system meet its uptime commitments, and will the DR plan work when needed?

Validates high availability configuration (Oracle Data Guard, RAC for on-premise; cloud redundancy for SaaS), failover procedures, backup and restore processes, RTO/RPO compliance, and recovery runbook accuracy.

Usability Testing

Question: Can real users operate the system effectively with the implemented configuration?

Often underweighted in ERP implementations, usability testing validates that screen layouts, navigation flows, search functionality, and report outputs meet user expectations — particularly for roles migrating from legacy systems with different interaction patterns.

Integration Performance Testing

Question: Can the integration layer sustain production transaction volumes without becoming a bottleneck?

Tests Oracle Integration Cloud (OIC) flows, inbound/outbound file-based integrations, real-time API integrations with third-party systems, and bulk data processing performance under load.

3. NFT Planning Framework

Effective NFT planning for Oracle Fusion follows a structured five-step framework. Rushing past any of these steps is the most common cause of NFT programs that deliver inconclusive or misleading results.

Step 1: NFT Strategy Definition

Define the overall approach before any test design begins:

• Which NFT categories are in scope for this implementation?
• Which Oracle Fusion modules and business processes are covered?
• What are the go-live readiness criteria that NFT must satisfy?
• What is the testing timeline relative to UAT and go-live?
• Who owns NFT — the implementation partner, the client IT team, or a shared model?

Document this in an NFT Strategy Document that is reviewed and signed off by the Project Sponsor, IT Lead, and key business stakeholders before any work begins.

Step 2: Workload Analysis

Gather quantitative data about how the system will be used in production. This data drives everything — test scenario selection, virtual user counts, transaction rates, and pass/fail criteria. Sources include:

• Current system usage reports (from legacy ERP, HR system, or procurement platform)
• Business stakeholder interviews (peak periods, transaction volumes, user counts)
• Oracle Fusion license counts (number of licensed users by module)
• IT capacity planning documents

Step 3: Test Scenario Design

Translate the workload analysis into specific test scenarios. Each scenario should describe a discrete, measurable business transaction that can be scripted and executed repeatedly with consistent results.

Step 4: Environment and Data Preparation

Identify and configure the test environment, prepare test datasets, and confirm that monitoring tools are in place before execution begins. This phase is consistently underestimated and is the most common cause of NFT timeline delays.

Step 5: Execution, Analysis, and Sign-Off

Execute tests in phases, analyze results against SLA thresholds, identify and remediate issues, and obtain formal sign-off from stakeholders before recommending go-live readiness.

4. Defining NFT Scope by Oracle Fusion Module

Not every Oracle Fusion module carries equal risk from a non-functional perspective. NFT scope should be prioritized based on business criticality, transaction volume, and integration complexity.

Financials (GL, AP, AR, Fixed Assets)

High NFT priority. Financial close is the most time-critical batch operation in Oracle Fusion. A financial close that runs for 10 hours in test but must complete in 4 hours for month-end is a go-live blocker.

Key NFT scenarios:

• Concurrent journal entry posting by multiple accountants during close period
• AP invoice import and matching (bulk volume — thousands of invoices)
• Financial close sequence: period-end accruals, allocations, consolidation, reporting
• AR cash receipts processing during high-volume collection periods
• Fixed asset depreciation run performance

Critical SLA: Financial close batch must complete within the agreed processing window (typically overnight or within a defined number of hours).

HCM & Payroll

High NFT priority. Payroll processing is the most resource-intensive Oracle Fusion operation for organizations with large workforces. A failed or delayed payroll run has immediate, visible impact on employees.

Key NFT scenarios:

• Concurrent employee self-service access during open enrollment periods
• Payroll calculation run for full employee population
• Mass absence submission (e.g., all employees submitting leave requests at start of new year)
• New hire onboarding workflow under concurrent load
• Payroll interface file generation for bank transfers

Critical SLA: Payroll run must complete within the defined processing window before bank transfer cutoff.

Procurement & SCM

Medium-High NFT priority. Procurement volume varies significantly by industry. Organizations with high purchase order volume (manufacturing, retail, healthcare) should treat this as high priority.

Key NFT scenarios:

• Concurrent purchase requisition creation by large buyer populations
• Purchase order approval workflow routing and notification under load
• Goods receipt processing during peak delivery periods
• Supplier invoice matching and approval
• Inventory transfer and cycle count processing

Oracle Integration Cloud (OIC)

High NFT priority for integration-heavy implementations. OIC sits in the critical path for most third-party integrations. An OIC bottleneck can degrade performance across all modules simultaneously.

Key NFT scenarios:

• Bulk inbound file processing (supplier data sync, bank statement import)
• Real-time outbound integration throughput (order status updates, payment confirmations)
• Error handling and retry behavior under load
• Concurrent integration flow execution

5. Workload Modeling for Oracle Fusion

A workload model is the quantitative foundation of your NFT plan. It translates business usage patterns into test parameters. Without a workload model, your test load numbers are guesses — and guesses produce tests that either miss real bottlenecks or create artificial ones.

Workload model components:

Parameter	Description	How to Determine
Peak Concurrent Users	Maximum simultaneous active users per module	License count × peak concurrency factor (typically 60–80% of active users are concurrent at peak)
Transaction Rate (TPH/TPS)	Business transactions per hour or second at peak	Current system reports + growth projection
Think Time	Average time a user spends between actions	User observation / session replay analysis
Ramp-Up Duration	How quickly users reach peak (e.g., start of business day)	Business hours analysis
Peak Duration	How long peak load is sustained	Business calendar (e.g., month-end close window)
Batch Window	Available time for batch processes	IT operations schedule

Example workload model — Financials module:

Module: Oracle Fusion Financials
Peak Period: Month-end close (last 3 business days of month)

Concurrent Users:
  - GL Accountants: 45 concurrent
  - AP Processors: 30 concurrent
  - AR Collectors: 20 concurrent
  - Finance Managers (approvals): 15 concurrent
  Total Peak Concurrent: 110 users

Transaction Rates:
  - Journal entries: 200 per hour
  - AP invoices: 500 per hour
  - AR receipts: 150 per hour

Batch Windows:
  - Period-end close: must complete within 4 hours (00:00–04:00)
  - AP payment run: must complete within 2 hours (22:00–00:00)

Think Time: 15–45 seconds between page interactions

Document a workload model for each Oracle Fusion module in scope and have it reviewed by the relevant business process owners before using it to design tests.

6. NFT Environment Strategy

The NFT environment is one of the most contentious topics in Oracle Fusion implementation projects — particularly for cloud (SaaS) deployments where environment access is controlled by Oracle.

Environment Requirements

For on-premise Oracle Fusion implementations:

The NFT environment should be as close to production as possible in terms of:

• Hardware specifications (CPU, RAM, storage I/O)
• Oracle Database version and configuration
• Network topology (load balancer, firewall rules)
• Data volume (production-scale dataset)

A common mistake is running NFT on an undersized environment and then assuming production will perform proportionally better. Non-linear performance characteristics in enterprise systems mean this assumption frequently fails.

For Oracle Fusion Cloud (SaaS) implementations:

Oracle provides a limited set of cloud environments. Typically, organizations have access to a Test environment and sometimes a Staging or Performance environment. Important considerations:

• Oracle authorization is required before conducting load tests on Oracle Fusion Cloud instances. This is a contractual obligation. Contact your Oracle account team or Customer Success Manager to obtain written authorization and understand any constraints (test windows, load limits, monitoring access).
• Shared infrastructure: Oracle Fusion Cloud runs on shared infrastructure. Your load test affects Oracle’s platform, not just your instance. This is why authorization matters.
• Environment availability: Cloud test environments are often shared across functional testing, UAT, and NFT. Coordinate with the project schedule to reserve exclusive NFT windows.

Environment Checklist

Before starting NFT execution, confirm:

• [ ] Environment is at the correct Oracle Fusion version/patch level
• [ ] Test data is loaded and validated
• [ ] Monitoring agents are installed and collecting data
• [ ] Network connectivity between JMeter hosts and target environment is confirmed
• [ ] Oracle authorization for load testing is obtained (for cloud)
• [ ] Environment is not shared with other active test activities during NFT windows
• [ ] Database statistics are current (stale statistics cause misleading query plans)
• [ ] Any environment-specific performance configurations (DB parameters, WebLogic tuning) mirror production intent

7. Test Data Strategy for NFT

NFT test data requirements differ fundamentally from functional test data. Functional tests need a few representative records to validate business rules. NFT tests need production-scale data volumes to surface real performance behavior.

Data volume targets for Oracle Fusion NFT:

Data Object	Minimum Volume	Rationale
Chart of Accounts Combinations	Full production COA	Query plans change at scale
Supplier Master	10,000+ suppliers	AP invoice matching performance
Employee Master	Full headcount	Payroll run performance
Open Invoices	50,000+ records	AP aging and matching performance
Purchase Orders	20,000+ open POs	Procurement workflow load
Inventory Items	Full item master	SCM transaction performance
Historical Transactions	2+ years of history	Reporting and close performance

Test user strategy:

Each virtual user in JMeter must correspond to a unique Oracle Fusion user account. Sharing user accounts across virtual users causes session conflicts and produces misleading results. For a test with 200 concurrent users, provision 200 dedicated test user accounts.

Organize test users by persona and module:

Performance test users:
  perf_ap_001 to perf_ap_050  (AP processors)
  perf_gl_001 to perf_gl_030  (GL accountants)
  perf_pr_001 to perf_pr_040  (Procurement officers)
  perf_hcm_001 to perf_hcm_080 (HCM self-service)

Data isolation: Performance test transactions must not contaminate functional test or UAT datasets. Use dedicated business units, cost centers, supplier groups, and ledgers for NFT where possible.

Data reset strategy: Plan for how test data will be reset between test runs. Options include:

• Database snapshot/restore (most reliable but requires DBA involvement)
• Reverse transaction scripts (post a journal to reverse test entries)
• Dedicated test data objects designed to be reused (e.g., POs that can be cancelled and re-created)

8. NFT Execution Phases and Timeline

NFT should not be a single event at the end of the project. A phased approach catches issues earlier when they are cheaper to fix.

Phase 1: NFT Readiness (4–6 weeks before NFT execution)

Activities:

• Finalize NFT strategy and get stakeholder sign-off
• Complete workload model
• Provision test environment and test users
• Load production-scale test data
• Complete script development and dry runs
• Confirm monitoring setup

Exit criterion: All scripts execute successfully in single-user mode with no errors.

Phase 2: Baseline Testing (Week 1 of NFT execution)

Run each scenario with a single virtual user (or very low load — 5–10% of peak) to establish baseline response times and confirm scripting correctness under minimal load.

Exit criterion: All scenarios complete without errors; baseline response times are documented.

Phase 3: Load Testing (Week 2–3)

Execute the core load tests at defined peak concurrent user counts. Run each scenario independently first, then run combined mixed-workload scenarios.

Activities per test run:

1. Pre-test environment health check
2. Execute test per defined load profile
3. Collect JMeter results and server-side metrics
4. Post-test analysis and issue logging
5. Environment reset for next run

Exit criterion: All scenarios meet defined SLA thresholds for response time and error rate.

Phase 4: Stress & Soak Testing (Week 3–4)

• Stress test: Ramp load to 150–200% of peak; document failure behavior and recovery
• Soak test: Run at 70% of peak for 8–24 hours; monitor for memory leaks and gradual degradation

Exit criterion: System recovers cleanly after stress test; no degradation observed during soak test.

Phase 5: Security & DR Testing (Week 4–5)

• Execute security test scenarios (access control, SoD validation, vulnerability scan)
• Execute DR failover test (with DBA and infrastructure team)
• Validate backup and restore procedures

Exit criterion: No security policy bypass identified; DR failover completes within RTO; data loss within RPO.

Phase 6: NFT Sign-Off (Week 5–6)

• Compile NFT completion report
• Present results to stakeholders
• Obtain formal sign-off or document remediation plan for outstanding items
• Issue go-live recommendation

Typical NFT timeline for a full Oracle Fusion implementation:

Weeks -8 to -5 before Go-Live: NFT preparation (environment, data, scripts)
Weeks -5 to -3 before Go-Live: NFT execution (load, stress, soak)
Weeks -3 to -2 before Go-Live: Security and DR testing
Week -2 before Go-Live: Remediation retest and sign-off
Week -1 before Go-Live: Final environment freeze and go-live preparation

Starting NFT less than 6 weeks before go-live significantly increases risk. Issues found in NFT often require infrastructure changes, Oracle patch applications, or configuration tuning that needs time to implement and retest.

9. Entry and Exit Criteria

Clear entry and exit criteria prevent the common scenario where NFT begins before the environment is ready, producing invalid results, or where NFT is signed off despite outstanding issues because of schedule pressure.

NFT Entry Criteria (must all be met before execution begins)

• [ ] Functional SIT is complete and sign-off obtained for modules in NFT scope
• [ ] NFT environment provisioned and health-checked
• [ ] Production-scale test data loaded and verified
• [ ] All NFT test scripts completed and validated in single-user mode
• [ ] Monitoring tools confirmed operational (JMeter dashboard, server metrics, DB monitoring)
• [ ] Oracle authorization for load testing obtained (for cloud deployments)
• [ ] NFT test window confirmed with no conflicting activities on the environment
• [ ] Test user accounts provisioned and access verified
• [ ] NFT strategy document signed off by Project Sponsor and IT Lead

NFT Exit Criteria (must all be met for go-live recommendation)

Performance:

• All critical transactions meet P95 response time SLA under peak load
• Error rate < 0.5% across all test scenarios
• No memory leaks or performance degradation observed in soak test
• System recovers cleanly after stress test to within 10% of baseline response times

Security:

• No unauthorized data access identified in security testing
• No active SoD conflicts in go-live role assignments
• All critical vulnerabilities remediated or formally accepted with documented risk

Availability / DR:

• Failover completes within agreed RTO
• Data loss within agreed RPO
• Recovery runbook validated and signed off by operations team

Usability:

• No usability issues rated Critical or High remain unresolved
• Key user representatives have signed off on usability findings

If any exit criterion is not met, the NFT program should not be signed off as complete. Outstanding items must either be remediated and retested, or formally accepted as risks with documented mitigations and sign-off from the Project Sponsor.

10. Roles and Responsibilities

NFT for Oracle Fusion requires coordination across multiple teams. Unclear ownership is a major cause of delays.

Role	Key Responsibilities
NFT Lead / Performance Test Manager	Defines the overall non-functional testing strategy, manages planning activities, coordinates stakeholders, and delivers executive reporting.
Performance Test Engineers	Develop and maintain JMeter scripts, execute performance tests, collect metrics, and analyze test results.
Security Tester	Designs and performs security testing activities, including vulnerability assessments and security validation.
Oracle Fusion Functional Leads	Provide business process expertise, define critical scenarios, validate test data, and interpret business-level test outcomes.
Infrastructure / DBA Team	Provision testing environments, monitor infrastructure performance, support troubleshooting, and optimize database performance.
Oracle Account Team	Facilitate Oracle Cloud load-testing approvals, provide Oracle-side monitoring support, and assist with performance investigations.
Project Manager	Coordinates schedules, manages risks and dependencies, tracks deliverables, and communicates progress to stakeholders.
IT / Business Sponsor	Approves the NFT strategy, reviews testing outcomes, and provides final go-live recommendations.

For cloud (SaaS) implementations, proactively engage Oracle’s Customer Success team early. Oracle has monitoring visibility into the cloud platform that the implementation team does not — their involvement in interpreting NFT results is valuable and sometimes necessary.

11. NFT Risks and Mitigations

Risk	Likelihood	Impact	Mitigation
NFT environment not representative of production	High	High	Document environment delta; escalate to steering committee if gap is too large.
Oracle authorization for cloud load testing delayed	Medium	High	Initiate authorization request 8+ weeks before planned NFT start.
Insufficient test data volume	High	High	Assign dedicated resource to test data preparation; start early.
NFT timeline compressed due to SIT overruns	High	High	Establish NFT as a fixed milestone; do not absorb SIT delays into NFT window.
Performance issues found late requiring infrastructure changes	Medium	High	Start NFT earlier; prioritize high-risk modules in Phase 1.
JMeter scripts fail due to Oracle Fusion patch/upgrade between script development and execution	Medium	Medium	Revalidate scripts after every environment patch.
Vendor/implementation partner deprioritizes NFT issues	Medium	High	Escalate via formal defect management process; track as project risks.
Security vulnerabilities requiring redesign of security model	Low	Very High	Conduct preliminary SoD analysis during design phase, not just in NFT.

12. Reporting and Sign-Off

The NFT completion report is the formal deliverable that enables the Project Sponsor to make an informed go-live decision. It should be factual, specific, and actionable — not a summary of activities, but a statement of system readiness.

NFT Completion Report structure:

Executive Summary
A one-page statement: did the system meet NFT exit criteria? If yes — recommended for go-live from an NFT perspective. If no — list outstanding items with severity and recommended disposition (fix before go-live, fix post go-live with accepted risk, or accepted as-is).

Test Scope and Coverage
Which modules, scenarios, and NFT categories were tested; which were descoped and why.

Performance Test Results
Results table for every test scenario showing: target SLA, achieved P50/P95/P99 response time, error rate, and Pass/Fail status. Accompanied by response time trend charts over the test duration.

Infrastructure Observations
Server-side metrics at peak load: CPU, memory, DB sessions, top SQL, WebLogic thread pool utilization. Identify any resource that reached concerning utilization levels (>80% sustained).

Issues and Defects
All NFT defects logged during execution, with severity, status, and resolution. Distinguish between resolved, in-progress, and accepted risks.

Recommendations
Specific, actionable recommendations — tuning parameters, infrastructure changes, configuration adjustments, monitoring alerts to implement before go-live.

Sign-Off Matrix
Formal sign-off by: NFT Lead, IT Lead, Project Manager, and Project Sponsor. This matrix documents that stakeholders have reviewed the results and accept the go-live recommendation.

Summary

Non-Functional Testing for Oracle Fusion ERP is not a checkbox activity — it is a structured program that determines whether your ERP investment will perform reliably for the business from day one. The key principles:

• Plan NFT early — start planning at least 10–12 weeks before go-live; preparation takes longer than execution
• Get authorization early — especially for Oracle Fusion Cloud, the authorization process has lead time that cannot be compressed
• Invest in test data — production-scale data is non-negotiable; NFT on thin datasets produces false confidence
• Cover all six NFT categories — performance alone is not sufficient; security, DR, and usability failures also block go-live readiness
• Enforce entry and exit criteria — resist schedule pressure to begin before the environment is ready or to sign off before criteria are met
• Report findings clearly — the NFT report enables a business decision; it must be clear, specific, and honest about outstanding risks

For the technical execution layer of your NFT program, refer to our companion articles: Using Apache JMeter for Oracle Fusion ERP Performance Testing: Concepts and Strategy covers UI-based load testing, and Oracle Fusion REST API Testing with JMeter covers integration and API layer testing.

Managing an Oracle Fusion ERP implementation and working through NFT planning? Share your experience or challenges in the comments — we would love to hear how other teams are approaching this.