AIM

TE.020 UNIT TEST SCRIPT

Balfour Beatty
RP007255
DM Entity: RP007255
Author:

Nikitha,Msat

Creation Date:

September 03, 2013

Last Updated:

September 03, 2013

Approvals:
<Approver 1>
<Approver 2>

Number_____

Copy

TE.020 Unit Test Script

Doc Ref:TE020.RP007255

Document Control
Change Record

Date

Author

Versio
n

Change Reference

3-Mar-11
03-Sept-13

Pratap
Nikitha raju

Draft
Draft
0.1

No
No Previous
Previous Document
Document

Reviewers

Name

Position

Distribution

Copy
No.

Name

Location

Note to Holders:
If you receive an electronic copy of this document and print it out, please
write your name on the equivalent of the cover page, for document control
purposes.
If you receive a hard copy of this document, please write your name on the
front cover, for document control purposes.

Company Confidential - For internal use only

Control

ii

Document

TE.020 Unit Test Script

Doc Ref:TE020.RP007255

Contents

Document Control
Overview

ii

Century Date Compliance

Unit Test Checklist
Form Information

2
2

Unit Test Specification 01

Unit Test Specification 02

Open and Closed Issues for This Deliverable

Open Issues
Closed Issues

7
7

Company Confidential - For internal use only

Control

iii

Document

Doc Ref:TE020.RP007255

Overview
This Unit Test Script verifies that each application extension conforms to
development standards by using this standards checklist. This test script
has been updated to incorporate the standards at this implementation site.
The tests outlined here were performed as the first step during unit testing
of each application extension.
This checklist covers only common and easily tested problems, and makes
no pretense of being a comprehensive check for compliance to standards.
If it were, this checklist would be as big as the UI standards document and
would take far too long to go through. All developers and testers have
already read the entire user interface standards document (and any
relevant areas of the coding standards document). They have checked
things they see against those standards even when they do not appear on
the checklist.
Further, after doing your own checking, the Tester will review every window
for standards problems missed by the initial tester. The Tester also
identified general user interface improvements possible beyond simple
standards issues. The Tester reviewed for possible overall improvements
(better ways to present the information or lay out the window, better
methods of how to do the necessary actions, and so on). This was done
allowing enough time to make any necessary changes, not just before
release. Testers were available for preliminary checks and user interface
ideas at any point during the design. Preliminary reviews were starting
with the un-coded window layout, or even a sketch, before beginning
programming code.
Regression testing was performed to check that bug fixes did not break
previously tested code. The testing execution plan is an iteration of the
following
Test -> Find Error -> Fix Bug Retest

Century Date Compliance

In the past, two character date coding was an acceptable convention due
to perceived costs associated with the additional disk and memory storage
requirements of full four character date encoding. As the year 2000
approached, it became evident that a full four character coding scheme
was more appropriate.
In the context of the Application Implementation Method (AIM), the
convention Century Date or C/Date support rather than Year2000 or Y2K
support is used. It is felt that coding for any future Century Date is now the
modern business and technical convention.
Every applications implementation team needs to consider the impact of
the Century Date on their implementation project. A part of the
implementation effort, all customizations, legacy data conversions, and
custom interfaces need to be reviewed for Century Date compliance.
Testing activities need to make sure that all interfaces and application
extensions are coded for Century Date compliance. Unit test scripts should
include steps for testing Century Date compliance.

Overview
Company Confidential - For internal use only

1 of 7

Doc Ref:TE020.RP007255

Unit Test Checklist

Form Information

DM Entity Name
ODI Scenario

RP007255

AP_M_1.12.0_supplier_type
AP_M_1.5.0_supplier_cat_status
AP_M_1.11.0_geo_region

File Path

C:\Incoming

Host Name

vmohsbabep46.oracleoutsourcing.c
om

Tester:

Nikitha

Date Tested:

03-Sept-2013

Overview
Company Confidential - For internal use only

2 of 7

Doc Ref:TE020.RP007255

Unit Test Specification 01

Basic Setups
Entity Name

Scenari
o
Step

Test
Step

Running the
DM entity in
Validation
Mode only

: ODI APPS Link Testing

Role

ODI

Action
or Path

Place .dat file in the

SFTP drive.
Make sure in the .dat
file at the header
level set threshold to
-1

Threshold -1
(Supplier
Geo Region
File)

Make sure all the

records pass in the
Geo region file

Expected Results

Actual Results

The ODI will send an email out to

a DM Loader team with
appropriate execution message
In this mode all the records are
validated against the target
instance and update the status
on each record with V for
validated and E for Error
record.

Expect
ed
Cycle
Time

Actual
Cycle
Time

Status

PASS

AP_M_1.11.0_geo_r
egion_CSUK_Test1.txt

All the geo region records are

successfully loaded through ODI

Running the
DM entity in
Validation
Mode only
Threshold -1
(Supplier
category
status File)

ODI

Place .dat file in the

SFTP drive.
Make sure in the .dat
file at the header
level set threshold to
-1
Make sure all the
records pass in the
supplier category
status file.

Note: ODI runs the packages in

validate/load mode from
XXBBMIG instead of APPS after
this change.
The ODI will send an email out to
a DM Loader team with
appropriate execution message
In this mode all the records are
validated against the target
instance and update the status
on each record with V for
validated and E for Error
record.

PASS

AP_M_1.5.0_supplier
_cat_status_CSUK_Test19.txt

All the category status records

are successfully loaded through
ODI
Note: ODI runs the packages in
validate/load mode from
XXBBMIG instead of APPS after
this change.
Unit Test Specification 01

7 of 7

Company Confidential - For internal use only

Doc Ref:TE020.RP007255
Scenari
o
Step

Test
Step

Running the
DM entity in
Validation
Mode only
Threshold -1
(Supplier
type File)

Role

ODI

Action
or Path

Place .dat file in the

SFTP drive.
Make sure in the .dat
file at the header
level set threshold to
-1
Make sure all the
records pass in the
Asbestos file.

Expected Results

Actual Results

The ODI will send an email out to

a DM Loader team with
appropriate execution message
In this mode all the records are
validated against the target
instance and update the status
on each record with V for
validated and E for Error
record.

Actual
Cycle
Time

Status

PASS

AP_M_1.12.0_suppli
er_type_CSUK_Test3.txt

All the Asbestos records are

successfully loaded through ODI
Note: ODI runs the packages in
validate/load mode from
XXBBMIG instead of APPS after
this change.

Unit Test Specification 01

Expect
ed
Cycle
Time

7 of 7

Company Confidential - For internal use only

Doc Ref:TE020.RP007255

Unit Test Specification 02

Functionality Testing
Scenari
o
Step

Test
Step

Role

Action
or Path

Expected Results

Unit Test Specification 01

Actual Results

7 of 7

Company Confidential - For internal use only

Expect
ed
Cycle
Time

Actual
Cycle
Time

Status

Doc Ref:TE020.RP007255

Open and Closed Issues for This Deliverable

Open Issues

ID

Issue

Resolution

Responsibility

Target
Date

Impact
Date

Resolution

Responsibility

Target
Date

Impact
Date

Closed Issues

ID

Issue

Unit Test Specification 01

7 of 7

Company Confidential - For internal use only