post, we detail the steps our Oracle Documaker QA team uses to automate some
regression test cases, specifically Documaker Interactive and WIP Edit Plug-in
using Oracle Functional Testing and OpenScript. This is the first in a series
of posts focused on Documaker regression testing.
Please note: This blog post does not explain how to install
or configure Oracle Documaker Interactive (DI), Oracle Documaker WIP Edit Plug-in or Oracle Automation Testing Suite (OATS). Installation and configuration
instructions for Documaker Interactive are included in the Oracle Documaker
Enterprise Edition (ODEE) Installation guide. WIP Edit Plug-in installation instructions
are in the Documaker Web-Enabled Solutions User Guide. Both of these guides are
available on the Oracle Technology Network (OTN) under Documaker on the Oracle
Insurance Documentation site. The blog post series “ODEE Green Field (Windows)”
also provides detailed information on Oracle Documaker Enterprise Edition
(ODEE) installation and Documaker Interactive.
Regression testing is the process of
retesting software after changes are made to ensure that the changes have not
broken any existing functionality.
Why bother to perform regression testing?
Oftentimes, tech companies release
new software features with much fanfare. There's nothing more irritating for
users than discovering that those new features have broken an existing
functionality—especially if that functionality is critical to their operations.
When that happens, business users must wait for the software developers to come
up with a fix. If that fix breaks something else, users must report the problem
to software developers and spend more time waiting. And the cycle
continues. The users are stalled, and their organization can’t benefit from the
new features as they wait. Meanwhile, the software developers are spending so
much time troubleshooting and fixing bugs which prevents them from working on
new features, enhancing existing features, and making the software more
beneficial for users. Regression tests can be executed
against the entire system (soup to nuts) or against specific products or areas.
Quality assurance (QA) staff, software or a combination of the two may conduct
More on manual testing
In manual testing, the QA team
follows a written test case, which includes action steps and expected results.
Manual tests can be useful to help familiarize new users with the product and
workflow. However, there are drawbacks to the manual method. Depending on the
nature of the test, the process can quickly become tedious and monotonous,
which may lead to QA staff overlooking problems. Situations that require QA
staff to run manual regression tests in multiple operating systems or multiple
browsers for multiple builds during the development cycle can leave the project
more vulnerable to potential oversight.
More on automated testing
In automated testing, automation
software is used to create and execute automation scripts. Automated testing
eliminates the potential for mistakes made during monotonous, repetitive manual
testing. And because you can run these tests anytime, day or night, you have
more time to increase your test coverage. Automated testing can run unattended
on different machines and operating systems, which frees up time for users to
spend on other important tasks such as functional testing of new features. Keep in mind that all tests are not
necessarily well suited for automated regression testing. For example, if an
interface is subject to frequent changes, manual testing is the best option
until the interface stabilizes.
Interactive is the interface used to create and edit documents for
distribution. It’s one of the components in Oracle Documaker Enterprise Edition (ODEE).
Oracle WIP Edit Plug-in
WIP Edit Plug-in is used in
conjunction with Documaker Interactive. It is a browser-based plug-in that lets
you create, edit and submit transactions in a WYSIWYG (what you see is what you
Oracle Automated Testing Suite (OATS)
Oracle Application Testing Suite or
OATS is an integrated testing solution. It consists of these integrated
OpenScript is used in Oracle
Functional Testing and Oracle Load Testing. It enables you to create automated
tests for Web Applications. You can record, script or manually create tests
using the different frameworks that the tool supports. OpenScript can also be
integrated with the test management component of Oracle Test Manager (OTM). You
can initiate the tests in OTM or OpenScript. OpenScript Workbench has multiple
views including a GUI (Graphical User Interface) and Java Code View. You can
record and play back tests in the GUI View, and script or edit tests using the Java Code View. More information
on OATS is available here.
framework is the set of assumptions, concepts and tools that provide support
for automated software testing. It includes the processes, procedures and environment
in which automated tests will be designed, created and implemented and the
results reported. There are
several different frameworks and scripting techniques. They include:
post, we’ll focus on two of these frameworks: keyword-driven and data-driven.
frameworks look very similar to manual test cases. In a keyword-driven framework,
the functionality of the application being tested is documented in a table as
well as in step-by-step instructions for each test. A keyword describes action
and input data. The test script code drives the application and data. Keyword-driven
frameworks require the development of data tables and keywords, which are
independent of the test automation tool used to execute them and the test
script code that "drives" the application-under-test and the data.
contains the keywords “Enter Client.” Enter Client is the functionality being
tested. The remaining columns contain data to execute the keyword. To enter
another client, you would add another table row.
Data-driven frameworks are driven
by test data. Test scripts are built-in so they will work with different sets
of data covering different scenarios without test script changes. In a data-driven framework, test input and output
values are read from data files (e.g., data pools, ODBC sources, CSV files,
Excel files, DAO objects, ADO objects, etc.) and are loaded into variables in the
scripts. In this framework, variables are used for both input values and output
verification values. Data-driven
frameworks are preferable for applications that use large amounts of input data
such as Documaker Interactive.
information on testing frameworks is available here.