The ORACLE Apps testing strategy defines five levels of testing. The ORACLE Testing Strategy deliverable contains detailed information on each testing level. The Developer’s Handbook only provides brief explanations for developers to use as a quick reference guide. The Developer’s Handbook does provide a minimal level of additional detail for those levels of testing in which developers themselves play a primary role. The levels of testing include:
· Construction Testing, which focuses on RICE elements and application configuration.
· Process Testing, which verifies delivered and enhanced software functionality.
· Integration Testing, which validates end-to-end business processes
· User Acceptance Testing, which validates the solution to the end-user community
· Technical Testing, which validate the hardware, software, and ancillary components function properly
Although not a separate deliverable from the code itself, developers will perform unit testing on each RICE component. The developer will be responsible for defining and executing the unit test for the development item. Unit tests will validate required functionality as detailed in the functional requirements document and that adequate exception handling is included in the developed item. Unit testing focuses on detailed testing of all paths through a piece of code. Developers should place emphasis on error processing. For example, when testing a custom form, developers should place special characters in all fields and have the form attempt to process. Upon successful completion of unit testing for a RICE component, the developers will conduct string testing on the component.
Developers perform all testing.
1.1.2 String Testing
String testing involves both the source and target systems for interfaces and conversions. In sting testing, the source application produces output, whether a flat file or a message. The target application receives and processes the input file or message. String testing proves that data elements transfer from the source to the target application. Upon successful completion of string testing, the technical team makes the components available for processing testing.
Developers from both the source and target divisions perform string testing.
Application configuration testing verifies the settings within the Oracle Applications. The tests ensure that the configured application meets documented requirements. Application configuration testing does not involve RICE components.
Developers have no responsibility for application configuration testing, although they may need to assist functional team members.
Members of the process project team will define and execute individual process tests on each function. Process testing combines the configured application and the RICE components into an integrated environment. Process testing takes place within the ORACLE TEAM and does not focus on division specific data. Upon successful completion of process testing a RICE component, the process team will make the development package available for Integration testing.
Developers do not create or execute process test. However, developers will investigate potential errors uncovered during testing and will resolve coding or Oracle bug issues as necessary.
1.3 Integration Testing
During integration testing, the process team performs end-to-end testing on processes. During this testing cycle, tests interfaces with the legacy application and integration with third parties, such as a bank. Upon successful completion of integration testing a RICE component, the process team will make the development package available for user acceptance testing.
1.4 User Acceptance Testing
’s user acceptance testing performs “a day in the life” testing scenario. For example, users execute daily, weekly, and monthly processes. ’s user community will perform user acceptance testing on each RICE component. User acceptance tests will validate required functionality as detailed in the functional requirements document. Upon successful completion of acceptance testing for a RICE component, the end-users will make the development package available for production.
Production readiness testing executes one time, immediately before the first production implementation. Production readiness testing occurs on the production hardware using the production software. Production readiness testing enables to test the exact hardware and software configurations that will exist after deployment to the Oracle Application. Production readiness testing focuses on validating that all the proper connections exist between the Oracle Application environment and other systems, whether internal or external to . (The UAT/FAT3 tests will serve as Production Readiness testing for the ORACLE implementation.)
1.5.2 Stress Testing
The ORACLE TEAM will conduct stress testing before the implementation of the pilot division, EPT. Stress testing will send a high volume of transactions through the system to test the performance of the application components. In the case of the ORACLE TEAM, stress testing will focus primarily on the interfaces.
1.5.3 Patch Testing
From a technical perspective, patch testing allows the person who applies the patch to ensure that repair software from the supplier will install completely and successfully and that the system is still accessible online. In addition, by having the functional resources participate, patch testing validates the functionality of an application after receiving a software update from the supplier. Patch testing identifies whether the patch fixes the known problem or not. In addition, patch testing also involves verifying that the patch does adversely affect any other software functionality.
1.5.4 Infrastructure Verification
Infrastructure verification testing validates whether new hardware platforms or network connections function as expected. Infrastructure verification testing only occurs when new hardware platforms or major network upgrades exist.