Automation

1 Automation
What is Automation
Automated testing is automating the manual testing process currently in use
1 Why Automate the Testing Process?
Today, rigorous application testing is a critical part of virtually all software development
projects. As more organizations develop mission-critical systems to support their business
activities, the need is greatly increased for testing methods that support business
objectives. It is necessary to ensure that these systems are reliable, built according to
specification, and have the ability to support business processes. Many internal and
external factors are forcing organizations to
ensure a high level of software quality and reliability.
In the past, most software tests were performed using manual methods. This required a
large staff of test personnel to perform expensive, and time-consuming manual test
procedures. Owing to the size and complexity of today’s advanced software applications,
manual testing is no longer a viable option for most testing situations.
Every organization has unique reasons for automating software quality activities, but
several reasons are common across industries.
Using Testing Effectively
By definition, testing is a repetitive activity. The very nature of application software
development dictates that no matter which methods are employed to carry out testing
(manual or automated), they remain repetitious throughout the development lifecycle.
Automation of testing processes allows machines to complete the tedious, repetitive work
while human personnel perform other tasks.
Automation allows the tester to reduce or eliminate the required “think time” or “read time”
necessary for the manual interpretation of when or where to click the mouse or press the
enter key.
An automated test executes the next operation in the test hierarchy at machine speed,
allowing
tests to be completed many times faster than the fastest individual. Furthermore, some
types of
testing, such as load/stress testing, are virtually impossible to perform manually.

Reducing Testing Costs
The cost of performing manual testing is prohibitive when compared to automated
methods. The
reason is that computers can execute instructions many times faster, and with fewer errors
than
individuals. Many automated testing tools can replicate the activity of a large number of
users (and their associated transactions) using a single computer. Therefore, load/stress
testing using
automated methods require only a fraction of the computer hardware that would be
necessary to
complete a manual test. Imagine performing a load test on a typical distributed client/server
application on which 50 concurrent users were planned.
To do the testing manually, 50 application users employing 50 PCs with associated
software, an
available network, and a cadre of coordinators to relay instructions to the users would be
required. With an automated scenario, the entire test operation could be created on a
single machine having the ability to run and rerun the test as necessary, at night or on
weekends without having to assemble an army of end users. As another example, imagine
the same application used by hundreds or thousands of users. It is easy to see why
manual methods for load/stress testing is an expensive and logistical nightmare.
Replicating Testing Across Different Platforms
Automation allows the testing organization to perform consistent and repeatable tests.
When
applications need to be deployed across different hardware or software platforms, standard
or
benchmark tests can be created and repeated on target platforms to ensure that new
platforms
operate consistently.
Repeatability and Control
By using automated techniques, the tester has a very high degree of control over which

types of
tests are being performed, and how the tests will be executed. Using automated tests
enforces
consistent procedures that allow developers to evaluate the effect of various application
modifications as well as the effect of various user actions.
For example, automated tests can be built that extract variable data from external files or
applications and then run a test using the data as an input value. Most importantly,
automated
tests can be executed as many times as necessary without requiring a user to recreate a
test
script each time the test is run.
Greater Application Coverage
The productivity gains delivered by automated testing allow and encourage organizations
to test
more often and more completely. Greater application test coverage also reduces the risk of
exposing users to malfunctioning or non-compliant software. In some industries such as
healthcare and pharmaceuticals, organizations are required to comply with strict quality
regulations as well as being required to document their quality assurance efforts for all
parts of
their systems.
2 Automation Life Cycle
Identifying Tests Requiring Automation
Most, but not all, types of tests can be automated. Certain types of tests like user
comprehension
tests, tests that run only once, and tests that require constant human intervention are
usually not
worth the investment to automate. The following are examples of criteria that can be used
to
identify tests that are prime candidates for automation.
High Path Frequency - Automated testing can be used to verify the performance of

application paths that are used with a high degree of frequency when the software is
running in full production.
Examples include: creating customer records, invoicing and other high volume activities
where
software failures would occur frequently.
Critical Business Processes - In many situations, software applications can literally
define or control the core of a company’s business. If the application fails, the company can
face extreme
disruptions in critical operations. Mission-critical processes are prime candidates for
automated
testing.
Examples include: financial month-end closings, production planning, sales order entry
and other core activities. Any application with a high-degree of risk associated with a failure
is a
good candidate for test automation.
Repetitive Testing - If a testing procedure can be reused many times, it is also a prime
candidate for automation. For example, common outline files can be created to establish a
testing session, close a testing session and apply testing values. These automated
modules can be used again and again without having to rebuild the test scripts. This
modular approach saves time and money when compared to creating a new end-to-end
script for each and every test.
Applications with a Long Life Span - If an application is planned to be in production for a
long period of time, the greater the benefits are from automation.
What to Look For in a Testing Tool
Choosing an automated software testing tool is an important step, and one which often
poses enterprise-wide implications. Here are several key issues, which should be
addressed when selecting an application testing solution.
Test Planning and Management
A robust testing tool should have the capability to manage the testing process, provide
organization for testing components, and create meaningful end-user and management

reports. It should also allow users to include non-automated testing procedures within
automated test plans and test results.
A robust tool will allow users to integrate existing test results into an automated test plan.
Finally, an automated test should be able to link business requirements to test results,
allowing users to evaluate application readiness based upon the application's ability to
support the business requirements.
Testing Product Integration
Testing tools should provide tightly integrated modules that support test component
reusability. Test components built for performing functional tests should also support other
types of testing including regression and load/stress testing. All products within the testing
product environment should be based upon a common, easy-to-understand language.
User training and experience gained in performing one testing task should be transferable
to other testing tasks. Also, the architecture of the testing tool environment should be open
to support interaction with other technologies such as defect or bug tracking packages.
Internet/Intranet Testing
A good tool will have the ability to support testing within the scope of a web browser. The
tests created for testing Internet or intranet-based applications should be portable across
browsers, and should automatically adjust for different load times and performance levels.
Ease of Use
Testing tools should be engineered to be usable by non-programmers and application end-
users. With much of the testing responsibility shifting from the development staff to the
departmental level, a testing tool that requires programming skills is unusable by most
organizations. Even if programmers are responsible for testing, the testing tool itself should
have a short learning curve.
GUI and Client/Server Testing
A robust testing tool should support testing with a variety of user interfaces and create
simple-to manage, easy-to-modify tests. Test component reusability should be a
cornerstone of the product
architecture.
Load and Performance Testing

The selected testing solution should allow users to perform meaningful load and
performance tests to accurately measure system performance. It should also provide test
results in an easy-to-understand reporting format.
3 Preparing the Test Environment
Once the test cases have been created, the test environment can be prepared. The test
environment is defined as the complete set of steps necessary to execute the test as
described in the test plan. The test environment includes initial set up and description of the
environment, and the procedures needed for installation and restoration of the
environment.
Description - Document the technical environment needed to execute the tests.
Test Schedule - Identify the times during which your testing facilities will be used for a
given test. Make sure that other groups that might share these resources are informed of
this schedule.
Operational Support - Identify any support needed from other parts of your organization.
Installation Procedures - Outline the procedures necessary to install the application
software to be tested.
Restoration Procedures - Finally, outline those procedures needed to restore the test
environment to its original state. By doing this, you are ready to re-execute tests or prepare
for a different set of tests.
Inputs to the Test Environment Preparation Process
Technical Environment Descriptions
Approved Test Plan
Test Execution Schedules
Resource Allocation Schedule
Application Software to be installed