Testing Reference 14 min read
Types of Software Testing in 2026: A Reference for Oracle ERP Teams
By SyntraFlow Team May 15, 2026
Software testing has accumulated dozens of named types over the past three decades. For Oracle Fusion Cloud and E-Business Suite teams in 2026, only a subset of these matter — but you need to know which ones, where each fits in the testing lifecycle, and how to apply them to Oracle's unique constraints (quarterly releases, Redwood UI, OIC integrations, security patches).
Software testing types form a pyramid. Lower-level types are cheap, fast and numerous. Higher-level types are expensive, slow but business-critical. For Oracle Fusion Cloud:
Base of pyramid: Unit tests, component tests — owned by developers. Rare for SaaS customers (you don't write Fusion's code) but applicable for OIC scripts, BI Publisher templates and custom extensions.
Middle of pyramid: Integration testing, SIT, regression testing. The biggest investment area for SaaS customers.
Top of pyramid: UAT, performance testing, security testing, business-cycle testing. Less frequent, higher impact.
Unit testing validates the smallest testable unit of code in isolation. For Oracle Fusion SaaS customers, unit testing applies to custom code: OIC scripts (Groovy/JavaScript), BI Publisher templates, Fusion Cloud Extensibility (App Composer customisations), custom REST extensions.
For Oracle EBS customers, unit testing applies more broadly: PL/SQL packages, custom forms, custom reports, Oracle Workflow customisations. Use frameworks like utPLSQL for EBS unit tests.
Validates that two or more modules or systems exchange data correctly. See our full guide to integration testing for Oracle Fusion. Covers OIC flows, REST/SOAP APIs, EDI, file-based interfaces, intra-module Oracle data flows.
Validates that two or more complete systems work together. SIT is broader than integration testing — it covers whole-system end-to-end flows. See our SIT explained guide for full breakdown.
UAT is the final business validation before go-live or before a release moves to production. Owned by real business users — not QA, not developers. Our UAT playbook for Oracle Fusion covers process, sample scripts and automation strategy.
Validates that previously-working functionality still works after a change. For Oracle Fusion, regression runs after every quarterly release (26A, 26B, 26C, 26D), every CPU/CSPU, every OIC change. See our regression testing complete guide.
Smoke testing — sometimes called "build verification testing" — is a rapid sanity check that critical functionality works at all. The phrase comes from hardware testing: power it on, see if smoke comes out.
For Oracle Fusion, smoke tests are run after every release deployment, every environment refresh, every major configuration change. A typical Oracle smoke test pack covers: login, key navigation, one transaction per critical module (one AP invoice, one journal post, one supplier creation). If smoke passes, the broader regression pack runs. If smoke fails, you have a fundamental problem to investigate before continuing.
Often confused with smoke testing. Sanity testing is narrower — it validates a specific change works as expected before running full regression. After a bug fix is delivered, sanity testing confirms the fix works before kicking off the broader regression pack.
Validates that the system performs acceptably under load. For Oracle Fusion, performance testing covers: page load times under user load, batch job throughput (payroll, period close, FBDI loads), integration throughput, OIC flow execution times. See our performance testing guide.
A subset of performance testing. Load testing validates the system under expected production load. Stress testing pushes beyond expected load to find breaking points. Spike testing validates handling of sudden load surges (end-of-quarter, payroll cycles, period close).
Validates that the system protects data and operations from unauthorised access. For Oracle: role-based access control validation, segregation of duties (SoD) testing, penetration testing of custom REST endpoints, validation of security patches (CPU, CSPU). See our Oracle SoD testing coverage.
Tests that the system delivers the functions specified in requirements. For Oracle, functional testing validates every business process works as configured — supplier onboarding, invoice processing, payroll runs, period close, financial reporting. Functional testing is the largest test category for SaaS customers.
Tests system characteristics that aren't direct business functions: performance, security, usability, accessibility, internationalisation. For Oracle Fusion: WCAG accessibility compliance, multi-currency/multi-language behaviour, browser compatibility, mobile responsiveness.
Unscripted testing where the tester learns the system and designs tests on the fly. For Oracle Fusion, exploratory testing is used to find issues that scripted tests miss — odd interaction patterns, edge cases in configuration, undocumented quirks.
Validates a complete business process from start to finish. Often used interchangeably with SIT or process testing. For Oracle: hire-to-retire, procure-to-pay, order-to-cash, record-to-report — each is an end-to-end flow crossing modules.
Quarterly release testing — unique to Oracle Cloud customers. Each of 26A, 26B, 26C, 26D requires a release-specific test pack. Full release testing checklist.
CPU / CSPU testing — validates Oracle security patches. Critical Security Patches tracker.
Redwood UI migration testing — validates that Oracle's gradual conversion to Redwood UI hasn't broken your tests or workflows.
OIC flow testing — validates Oracle Integration Cloud orchestrations.
The core types relevant to Oracle Fusion Cloud are: unit testing, integration testing, system integration testing (SIT), user acceptance testing (UAT), regression testing, smoke testing, performance testing, load testing, security testing and functional testing.
Smoke testing is a broad, rapid check that critical functionality works at all. Sanity testing is a narrow check that a specific recent change works as expected. Smoke is wider; sanity is deeper but narrower.
Functional testing validates that the system does what users need (process invoices, run payroll, close periods). Non-functional testing validates how well it does those things (performance, security, accessibility, usability).
For SaaS Oracle Fusion: integration testing, SIT, UAT, regression, smoke, performance, security and functional testing. Unit testing applies only to custom code (OIC scripts, BI Publisher, App Composer customisations).
Oracle EBS supports all of the above plus deeper unit testing (PL/SQL via utPLSQL), forms testing, custom report testing and Oracle Workflow validation.
At minimum: regression, smoke, integration testing, SIT and a delta-UAT. The specific scope depends on what changed in the release. See SyntraFlow Release Intelligence.