1
Testing::
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.
2 comments:
Post a Comment