Oracle Apps Testing

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

1.1        Construction Testing

1.1.1          Unit Testing

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.

1.1.3          Application Configuration 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.

1.2        Process Testing

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.

1.5        Technical Testing

1.5.1          Production Readiness Testing

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.

Oracle Reserved Words

1          Appendix A – Oracle Reserved Words

1.1        Oracle 8.1.7 Reserved Words

This appendix lists Oracle reserved words.  Oracle changes reserved words with each version of its product.  For a complete listing of reserved words, developers must use https://metalink.oracle.com.  Words followed by an asterisk (*) are also ANSI reserved words.  Developers must only use these words in Oracle related context.

Note: In addition to the following reserved words, Oracle uses system-generated names beginning with "SYS_" for implicitly generated schema objects and sub-objects.  Oracle discourages developers from using this prefix in the names explicitly given to custom schema objects and sub-objects to avoid possible conflict in name resolution.

ACCESS

ADD*

ALL*

ALTER*

AND*

ANY*

AS*

ASC*

AUDIT

BETWEEN*

BY*

CHAR*

CHECK*

CLUSTER

COLUMN

COMMENT

COMPRESS

CONNECT*

CREATE*

CURRENT*

DATE*

DECIMAL*

DEFAULT*

DELETE*

DESC*

DISTINCT*

DROP*

ELSE*

EXCLUSIVE

EXISTS

FILE

FLOAT*

FOR*

FROM*

GRANT*

GROUP*

HAVING*

IDENTIFIED

IMMEDIATE*

IN*

INCREMENT

INDEX

INITIAL

INSERT*

INTEGER*

INTERSECT*

INTO*

IS*

LEVEL*

LIKE*

LOCK

LONG

MAXEXTENTS

MINUS

MLSLABEL

MODE

MODIFY

NOAUDIT

NOCOMPRESS

NOT*

NOWAIT

NULL*

NUMBER

OF*

OFFLINE

ON*

ONLINE

OPTION*

OR*

ORDER*

PCTFREE

PRIOR*

PRIVILEGES*

PUBLIC*

RAW

RENAME

RESOURCE

REVOKE*

ROW

ROWS*

ROWID

ROWNUM

SELECT*

SESSION*

SET

SHARE

SIZE

SMALLINT*

START

SUCCESSFUL

SYNONYM

SYSDATE

TABLE*

THEN*

TO*

TRIGGER

UID

UNION*

UNIQUE*

UPDATE*

USER*

VALIDATE

VALUES*

VARCHAR*

VARCHAR2

VIEW*

WHENEVER*

WHERE

WITH*

1.2        PL/SQL 8.1.7 Reserved Words

PL/SQL reserves the words listed in this appendix.  That is, they have a special syntactic meaning to PL/SQL.  Therefore, developers should not use them to name program objects such as constants, variables, or cursors.  SQL also reserves some of these words (marked by an asterisk).  Therefore, developers should not use them to name schema objects such as columns, tables, or indexes.  Oracle changes reserved words with each version of its product.  For a complete listing of reserved words, developers must use https://metalink.oracle.com. 

ALL*

ALTER*

AND*

ANY*

ARRAY

AS*

ASC*

AT

AUTHID

AVG

BEGIN

BETWEEN*

BINARY_INTEGER

BODY

BOOLEAN

BULK

BY*

CHAR*

CHAR_BASE

CHECK*

CLOSE

CLUSTER*

COLLECT

COMMENT*

COMMIT

COMPRESS*

CONNECT*

CONSTANT

CREATE*

CURRENT*

CURRVAL

CURSOR

DATE*

DAY

DECIMAL*

DECLARE

DEFAULT*

DELETE*

DESC*

DISTINCT*

DO

DROP*

ELSE*

ELSIF

END

EXCEPTION

EXCLUSIVE*

EXECUTE

EXISTS*

EXIT

EXTENDS

FALSE

FETCH

FLOAT*

FOR*

FORALL

FROM*

FUNCTION

GOTO

GROUP*

HAVING*

HEAP

HOUR

IF

IMMEDIATE*

IN*

INDEX*

INDICATOR

INSERT*

INTEGER*

INTERFACE

INTERSECT*

INTERVAL

INTO*

IS*

ISOLATION

JAVA

LEVEL*

LIKE*

LIMITED

LOCK*

LONG*

LOOP

MAX

MIN

MINUS*

MINUTE

MLSLABEL*

MOD

MODE*

MONTH

NATURAL

NATURALN

NEW

NEXTVAL

NOCOPY

NOT*

NOWAIT*

NULL*

NUMBER*

NUMBER_BASE

OCIROWID

OF*

ON*

OPAQUE

OPEN

OPERATOR

OPTION*

OR*

ORDER*

ORGANIZATION

OTHERS

OUT

PACKAGE

PARTITION

PCTFREE*

PLS_INTEGER

POSITIVE

POSITIVEN

PRAGMA

PRIOR*

PRIVATE

PROCEDURE

PUBLIC*

RAISE

RANGE

RAW*

REAL

RECORD

REF

RELEASE

RETURN

REVERSE

ROLLBACK

ROW*

ROWID*

ROWNUM*

ROWTYPE

SAVEPOINT

SECOND

SELECT*

SEPARATE

SET*

SHARE*

SMALLINT*

SPACE

SQL

SQLCODE

SQLERRM

START*

STDDEV

SUBTYPE

SUCCESSFUL*

SUM

SYNONYM*

SYSDATE*

TABLE*

THEN*

TIME

TIMESTAMP

TO*

TRIGGER*

TRUE

TYPE

UID*

UNION*

UNIQUE*

UPDATE*

USE

USER*

VALIDATE*

VALUES*

VARCHAR*

VARCHAR2*

VARIANCE

VIEW*

WHEN

WHENEVER*

WHERE*

WHILE

WITH*