Oracle Application Testing Suite is a comprehensive, integrated testing solution

for Web applications, Web Services, packaged Oracle Applications and Oracle
Databases.
Description/History[edit]

The test solution was originally developed by RSW, who was bought by Teradyne that
created the software and call center test company Empirix. Empirix eTest Suite was
acquired by Oracle in June 2008 and was rebranded as Oracle Application Testing
Suite

The Oracle Application Testing Suite is part of the Oracle Enterprise Manager
product family and comprises the following tightly integrated products:[1]

Oracle Load Testing for scalability, performance and load testing.

Oracle Functional Testing for automated functional and regression testing.
Oracle Flow Builder is introduced as part of Functional testing along with the
Release of OATS 12.3.0
Oracle Test Manager for test process management, including test requirements
management, test management, test execution and defect tracking.
Oracle Application Testing Suite also provides a series of integrated testing
accelerators for testing Oracle packaged applications and SOA applications. These
accelerators enable enhanced scripting capabilities for more efficient and
optimized testing.

Supported technology/Applications[edit]

Web/HTML, Adobe Flex, Siebel, Oracle E-business Suite, Oracle Fusion Applications,
JD Edwards EnterpriseOne, Application Development Framework, Oracle Forms, Web
Services, Oracle Databases

Scripting platform[edit]

Oracle Application Testing Suite have one unified scripting platform called
OpenScript.[2][3][4] This is an Eclipse based scripting platform that provides a
graphical user interface and the possibility to extend scripts by using Java code.

Languages[edit]

Oracle Functional Testing and Oracle Load Testing both uses the same scripting
platform (OpenScript) and scripts may be extended by using the JAVA programming
language.

License models[edit]

Oracle Functional Testing is licensed based on NUP (Named User Plus). Oracle Test
Manager is licensed based on NUP (Named user Plus). Oracle Load Testing is licensed
based on:

Number of Processors for the Load Testing Controller

Number of Virtual Users to be simulated
The base license covers web applications support. Additional accelerators may be
licensed as needed.

Manual testing is the process of manually testing software for defects. It requires
a tester to play the role of an end user and use most of all features of the
application to ensure correct behavior. To ensure completeness of testing, the
tester often follows a written test plan that leads them through a set of important
test cases.
Overview[edit]
A key step in the process is, testing the software for correct behavior prior to
release to end users.

For small scale engineering efforts (including prototypes), exploratory testing may
be sufficient. With this informal approach, the tester does not follow any rigorous
testing procedure, but rather explores the user interface of the application using
as many of its features as possible, using information gained in prior tests to
intuitively derive additional tests. The success of exploratory manual testing
relies heavily on the domain expertise of the tester, because a lack of knowledge
will lead to incompleteness in testing. One of the key advantages of an informal
approach is to gain an intuitive insight to how it feels to use the application.

Large scale engineering projects that rely on manual software testing follow a more
rigorous methodology in order to maximize the number of defects that can be found.
A systematic approach focuses on predetermined test cases and generally involves
the following steps.[1]

Choose a high level test plan where a general methodology is chosen, and resources
such as people, computers, and software licenses are identified and acquired.
Write detailed test cases, identifying clear and concise steps to be taken by the
tester, with expected outcomes.
Assign the test cases to testers, who manually follow the steps and record the
results.
Author a test report, detailing the findings of the testers. The report is used by
managers to determine whether the software can be released, and if not, it is used
by engineers to identify and correct the problems.
A rigorous test case based approach is often traditional for large software
engineering projects that follow a Waterfall model.[2] However, at least one recent
study did not show a dramatic difference in defect detection efficiency between
exploratory testing and test case based testing.[3]

Testing can be through black-, white- or grey-box testing. In white-box testing the
tester is concerned with the execution of the statements through the source code.
In black-box testing the software is run to check for the defects and is less
concerned with how the processing of the input is done. Black-box testers do not
have access to the source code. Grey-box testing is concerned with running the
software while having an understanding of the source code and algorithms.[citation
needed]

Static and dynamic testing approach may also be used. Dynamic testing involves
running the software. Static testing includes verifying requirements, syntax of
code and any other activities that do not include actually running the code of the
program.

Testing can be further divided into functional and non-functional testing. In

functional testing the tester would check the calculations, any link on the page,
or any other field which on given input, output may be expected. Non-functional
testing includes testing performance, compatibility and fitness of the system under
test, its security and usability among other things.

Stages[edit]

This section may stray from the topic of the article into the topic of another
article, Software Testing. Please help improve this section or discuss this issue
on the talk page.
There are several stages. They are:

Unit Testing
This initial stage in testing normally carried out by the developer who wrote the
code and sometimes by a peer using the white box testing technique.
Integration Testing
This stage is carried out in two modes, as a complete package or as an increment to
the earlier package. Most of the time black box testing technique is used. However,
sometimes a combination of Black and White box testing is also used in this stage.
Software Testing
After the integration have been tested, software tester who may be a manual tester
or automator perform software testing on complete software build. This Software
testing consists of two type of testing:
Functional(to check whether SUT(Software under testing) is working as per the
Functional Software Requirement Specification[SRS=FRS+NFRS(Non-Functional
Requirements Specifications)] or NOT). This is performed using White Box testing
techniques like BVA, ECP, Decision Table, Orthogonal Arrays. This Testing contains
four Front-End testing(GUI,Control flow,Input Domain, Output or Manipulation) and
one Back-End testing i.e. Database testing.
Non-Functional Testing /System Testing/Characteristics Testing(to check whether SUT
is working as per the NFRS, which contains characteristics of the Software to be
developed like Usability, Compatibility, Configuration, Inter System Sharing,
Performance, Security)
System Testing
In this stage the software is tested from all possible dimensions for all intended
purposes and platforms. In this stage Black box testing technique is normally used.
User Acceptance Testing
This testing stage carried out in order to get customer sign-off of finished
product. A 'pass' in this stage also ensures that the customer has accepted the
software and is ready for their use.
Release or Deployment Testing
Onsite team will go to customer site to install the system in customer configured
environment and will check for the following points:
Whether SetUp.exe is running or not.
There are easy screens during installation
How much space is occupied by system on HDD
Is the system completely uninstalled when opted to uninstall from the system.
Comparison to Automated Testing[edit]
Test automation may be able to reduce or eliminate the cost of actual testing. A
computer can follow a rote sequence of steps more quickly than a person, and it can
run the tests overnight to present the results in the morning. However, the labor
that is saved in actual testing must be spent instead authoring the test program.
Depending on the type of application to be tested, and the automation tools that
are chosen, this may require more labor than a manual approach. In addition, some
testing tools present a very large amount of data, potentially creating a time
consuming task of interpreting the results.

Things such as device drivers and software libraries must be tested using test
programs. In addition, testing of large numbers of users (performance testing and
load testing) is typically simulated in software rather than performed in practice.

Conversely, graphical user interfaces whose layout changes frequently are very
difficult to test automatically. There are test frameworks that can be used for
regression testing of user interfaces. They rely on recording of sequences of
keystrokes and mouse gestures, then playing them back and observing that the user
interface responds in the same way every time. Unfortunately, these recordings may
not work properly when a button is moved or relabeled in a subsequent release. An
automatic regression test may also be fooled if the program output varies
significantly.
ERP (Enterprise Resource Planning) system

Oracle CRM formerly known as Siebel