An AUTOMATED TESTING INSTITUTE Publication - www.automatedtestinginstitute.

com

A
S
utomated .......
T
oftware esting MAGAZINE
December 2010 $8.95

TechnicaL
vsvs
Non- Technical
Skills in Test Automation

Automation
Supercharged
Mod-out Your
Automation To Make
It More Effective

Showing Up On
Management’s
Radar
6 Inevitable Questions
You Must Be Prepared
To Answer

Hot Tutorial: Passing Parameters From Quality Center to QTP

 Verify/ATI Conference 2011
Venture Beyond the Abstract

Save The Date!

September 19 - 21, 2011
Arlington, VA

The Test Automation Conference You’ve Been Waiting For

Call for Papers Opening Soon. Visit Conference Site For More Information

www.verifyati.com
A
S
utomated
T
oftware esting
December 2010, Volume 2, Issue 5

Contents
Cover Story
Technical Vs Non-Technical Skills 16
There is a general perception that testers must be or become technical, i.e. programmers, if they are to become
involved in automation. This is not necessarily the case, however. Read this article to learn more about the role of
the testers and test automators in test automation. By Dorothy Graham

Features
Automation Supercharged 24
Just like many automobile enthusiasts “mod-out” their muscle cars, you have the option to mod-out your automation for a
higher degree of technical output. By J.L. Perlin

Showing Up On Management’s Radar 28

When management locks its sights onto your automation efforts, you better be able to respond quickly, or risk getting shot
down. Read this article to learn the 6 questions from management you must be prepared to answer. By Dion Johnson

Columns & Departments

Editorial 4
Flipping the Automation Coin I ‘B’log to U 34
Learn why technical and non-technical skills are both Read featured blog posts from the web.
important to test automation. Hot topics in automation 38
QC/QTP Parameters Are Hot!
Authors and events 6
Why the community loves ATI’s “Passing Parameters
Learn about AST authors and upcoming events.
From Quality Center To QTP” Tutorial
Sweat the technique 8
Custom Report Generation The Automated Software Testing (AST) Magazine is an Automated Testing
Institute (ATI) publication.
Learn how to customize your test management tool to For more information regarding the magazine visit
http://www.astmagazine.automatedtestinginstitute.com
generate custom reports.
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 3
Editorial

Flipping the Automation Coin

by Dion Johnson
What does test automation truly entail?
Is it all just about highly technical work?
Is it simply about scripting? Is it a simple
matter of objects, properties, methods
and syntax? Am I going to ask rhetorical
questions during this entire article? The
answers to these questions are ‘No’.
Our I B’Log to U department includes a
statement from Elisabeth Hendrickson’s
blog in which she poses the following
question:

For years, whenever someone

asked me if I thought testers had
to know how to write code, I’ve
responded: “Of course not.”

Her statement, however, was about

testers doing general testing work. It didn’t
address work specific to test automation.
So, what about, test automation tasks?
ATI’s forth coming Automation Body
of Knowledge Guidebook (http://www.
abok.automatedtestinginstitute.com)
includes the following excerpt:
Software test automation is the use of
software to test or support the testing of
sentences of the above paragraph then
you might believe that test automation
is strictly technical. If you also subscribe
to the final sentence, however, then it is
probably your belief that it is so much
more. The phrase “general support
for and implementation of” is short,
but packs a lot of power. Essentially
look at the big picture and move the entire
effort in the right direction. This issue of
the AST magazine is therefore devoted
to an exploration of technical and non-
technical skills that together make up
two sides of the same test automation
coin. In our cover story, Ms. Dorothy
Graham addresses the relationship

Successful implementation of test automation typically

requires some programming expertise as well as planning and
management expertise.
other software known as an application
under test (AUT). This includes the
use of software to dynamically setup
test preconditions, produce test data,
execute test procedures against the
AUT, and dynamically compare actual
results to expected results of a test. Also,
this may involve the use of software
to dynamically collate test results and
produce meaningful test charts, graphs
and reports that effectively relay those
results to stakeholders. Additionally,
it entails general support for and
implementation of software tools that
integrate with and help to facilitate the
testing process.
If you subscribe to only the first three
it means that test automation is not
all technical, and to assume that it is
would do a major disservice to your
efforts. Successful implementation
of test automation typically requires
some programming expertise as well
as planning and management expertise.
You must have someone that is able to
understand code cleanup and memory
leaks, along with someone that knows
how to calculate return on investment
and make decisions about what should
be automated. The point being made
here is that a test automation effort
should include resources with both a
microscopic set of skills that are able to
get into the technical weeds, as well as a
macroscopic set of skills that are able to
between technical and non-technical
automation skills in an article entitled,
“Technical vs. Non-Technical Skills in
Test Automation”. Then focusing more
attention on the technical side of the
fence, Mr. J.L. Perlin provides a high
energy article entitled, “Automation
Supercharged”. In this article Perlin
lets us know how we can “mod-out”
our test automation efforts much like
people do their muscle cars to make them
more efficient and effective. Finally,
Mr. Dion Johnson (that would be me),
shifts direction and looks at some non-
technical concerns in an article entitled,
“Showing Up On Management’s Radar:
6 Inevitable Questions You Must Be
Prepared to Answer”.

4 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

Are You Contributing
Content Yet?
The Automated Testing Institute relies heavily on the automated testing
community in order to deliver up-to-date and relevant content. That’s why
we’ve made it even easier for you to contribute content directly to the ATI
Online Reference! Register and let your voice be heard today!

As a registered user you can submit content directly to the site, providing you with
content control and the ability to network with like minded individuals.
Community
Comments Box >> Community Comments Box - This comments box, available on the home page of
the site, provides an opportunity for users to post micro comments in real time.
>> Announcements & Blog Posts - If you have interesting tool announcements, or
you have a concept that you’d like to blog about, submit a post directly to the ATI
Announcements & Online Reference today. At ATI, you have a community of individuals that would love
Blog Posts to hear what you have to say. Your site profile will include a list of your submitted
articles.
>> Automation Events - Do you know about a cool automated testing meetup,
webinar or conference? Let the rest of us know about it by posting it on the ATI site.
Automation Add the date, time and venue so people will know where to go and when to be there.
Events
Learn more today at http//www.about.automatedtestinginstitute.com
Authors and Events

Who’s In This Issue?

Dorothy Graham has worked in software
testing for over 30 years. Originally from the US,
A
S
utomated
T
oftware esting
her first job was developing testing tools for Bell
Labs in New Jersey. After emigrating to the UK, Managing Editor
she worked as a developer for Ferranti Computer Dion Johnson
Systems in Manchester for 7 years. She developed
Contributing Editor
training courses in software engineering for the
Edward Torrie
National Computing Centre before becoming an independent consultant
specializing in software testing. She founded Grove Consultants in 1988. Director of Marketing and Events
During her 20 years with them, Grove gained a reputation for the high quality Christine Johnson
of their training materials and presentations, and established a world-wide
client base. In 2008 she left Grove to work again as an independent consultant.
A PUBLICATION OF THE AUTOMATED
She is co-author of three books, was Programme Chair for EuroSTAR 2009, TESTING INSTITUTE
was a founding member of the ISEB Software Testing Board, and is a popular
and entertaining speaker at conferences and events world-wide.

J.L. Perlin offers a featured article that provides an

approach for handling modern day technology changes.
Perlin has over 20 years of manual and automated CONTACT US
testing experience and has managed QA teams in both AST Magazine
the public and private sector for organizations including astmagazine@automatedtestinginstitute.com
Lockheed Martin, Social Security Administration ATI Online Reference
(SSA), General Electric, and the Centers for Medicare contact@automatedtestinginstitute.com
& Medicaid Services (CMS). You can email Mr. Perlin at jeffrey_perlin@
yahoo.com

ATI and Partner Events

Dion Johnson has several years of
experience in providing IT services to both February 14, 2011
government and private industry. With a Bachelor Open Source Test Automation
of Science degree in Electrical Engineering, Tools Love-In (OSTATLI)
he has spent much of his professional career as http://agilistry.com/events/ostatli/
a consultant in the areas of quality assurance
September 19-21, 2011
(QA), quality control (QC), software process
improvements, requirements analysis and software test automation. Verify/ATI Conference 2011
www.verifyati.com
As a regular conference speaker and presenter, Dion has delivered
award winning and highly acclaimed presentations at many of the
most prestigious industry conferences, including the StarEast and
StarWest International Conference on Software Testing, Analysis
and Review, and the Quality Assurance Institute Conference. He also
teaches college level classes relative to testing and test automation,
and has several published articles in various IT publications.
6 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
 For more information, visit http://www.networking.automatedtestinginstitute.com
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 7
Sweat the Technique

The ins and OUTS of Test Management Tools

Create Custom Reports in 9 Steps

Despite the title, this article is more about the OUTs, 1. Create template structure
than the Ins; the Output to be more exact. Very often one 2. Connect to test management tool data store
of the serious limiting factors of test management tools is
the format in which data comes out. Test teams and their 3. Open template file
stakeholders get used to managing and seeing data, such as 4. Query header data
test case reports, in a specific way. For example, it’s not
5. Add header data to report
uncommon for testers to manage and maintain test
cases using Microsoft Word templates, but as the test 6. Query dynamic data
bed grows and this approach becomes increasingly 7. Insert rows in the dynamic data report table
unmanageable, project leads often work to introduce
a test management tool. This move towards a test 8. Add dynamic data to report
management tool is often met by resistance for a number of 9. Save and Close template
reasons, and one of those reasons is that the tool
won’t allow them to export the test cases Step 1. Create template structure
in the format they’re used to
This step is the only one
seeing. Sometimes this can
that is not programmatic.
be mitigated by easing
It calls for the creation of a
all pertinent parties into
formatted Word template file
the new way of viewing
(.dot or .dotx). This template
the data. Other times it’s not
file will be accessed and used
that simple. While it may be fine for the
by the custom exporter script
test designer to change the way they manage and
that generates a test case from the
view the data, there may be contractual obligations that
test management tool to MSWord.
force the project team to provide stakeholders (sometimes
The use of a template greatly reduces the amount of code that
government stakeholders) with test case reports in a specific
the custom exporter will require, because instead of building
format. So whether the issues are contractual or cultural, there
the Word report from scratch, the script will simply extract the
is often a need to print out custom Word reports. This can be
desired data from the tool and place it in the predefined template
accomplished in 9 Steps:

Figure 1: Test Case Template

8 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

 Sweat the Technique

locations. For the purposes of this article,

‘Connect to Test Tool Data Store we will use the template illustrated in
Figure 1. This file will be saved as C:\\
testCaseTemplate.dot.
‘Invoke Word
This template is composed of two
Word tables. It’s important to note the
index and structure (number of rows and
‘Open New Word Document Based on Template columns) of the tables, because we’ll
refer to this information when we begin
scripting. Word table 1 is the Header
Information table and it has 2 columns
and 4 rows.

• Row 1: Test Case Name

• Row 2: Test Case Description
• Row 3: Test Case Prerequisites
• Row 4: Post Conditions
‘Get Header Data The first column of this table is simply
for informational purposes. The second
column will be used for storing the
pertinent test header data.

Word table 2 is the Test Case Steps

‘Identify the Word Tables table and it has 5 columns and two rows.

• Column 1: Step Number

‘Put Header Data in Word Document • Column 2: Step Description

• Column 3: Step Expected Results
• Column 4: Step Actual Results
• Column 5: Step Pass/Fail Status
‘Get Test Step Data The first row of this table is simply for
informational purposes. The second row
is currently blank, but will be filled in
‘Insert A Row in the Test Step Table For Each Test Step Retrieved
based on the data that exists in the test
management tool. The script will also
dynamically add rows to this table based
‘Put Test Step Data in Word Document on the rows of data that exist in the tool.

Step 2.Connect to test management

tool data store

The mechanism for connecting to

the test management tool varies based
on the test management tool you’re
‘Save Word Document
implementing. A customization module
may be available that provides the ability
to write internal scripts that interface
‘Cleanup with the tool and its data via an API.
Other tools might offer only the ability
to connect directly to its data store from
an external script via a connection object
(i.e. ADODB object).

If you’re unsure of how to access your

Figure 2: ‘Generate Test Case’ Exporter Function

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 9


Figure 3: Stub Functions
tools data from a script, you can check
the tool’s documentation or find an online
forum that can provide some guidance.
For the purposes of this article
a placeholder function has been
created called ConnectToDataStore.
This function is used on line 3 of the
GenerateTestCaseReport function
illustrated in Figure 2.
Step 3. Open template file
Upon accessing the data store, the next
step is to open a new Word document
based on the template file that was created
in Step 1. This is illustrated in lines 5
through 20 of Figure 2. Line 6 is used to
10 Automated Software Testing Magazine
programmatically open an instance of
Microsoft Word. This instance is tied to the
ObjWord variable. When initially opened,
Word is invisible, so to make it visible
on the screen, the Visible property is set
to ‘True’. If you don’t want Microsoft to
be visible during the export process, but
instead elect for the processing to occur
behind the scenes, you can set the property
to ‘False’ or don’t set it at all (the default
is False).
Lines 10 and 11 initialize variables
that store the name and path of the
template file. Line 12 is used to instantiate
the FileSystemObject object. This object
is used in the if block beginning at line 13
www.automatedtestinginstitute.com
to make sure the template file exists prior
to attempting to open it. If the template
file exists, the statement on line 14 creates
a new word document based on that
template and the script moves on.
Step 4. Query header data
Just as the mechanism for connecting
to the data store varies with each test
management tool, so does the mechanism
for obtaining data from the data store. For
the purposes of this article, two stubs –
illustrated in Figure 3 – have been created
to simulate the querying of a data store:
• QueryHeaderData
• QueryTestStepData
Lines 23 through 26 of the
exporter function in Figure 2 use the
QueryHeaderData function to get the data
that will be placed in the report document.
Step 5. Add header data to report
Since we identified the structure
of the template file tables, this step is
pretty simple with a little knowledge
of MS Word’s object model. First, the
script accesses the tables in lines 29 and
30, and stores references to the tables in
variables. Lines 33 through 36 access the
header table by its variable reference in
order to place the header data in the report
document.
Step 6. Query dynamic data
This is essentially the same as Step
4, with the exception of the data actually
being queried. This time, we’re getting
the dynamic data. The data is considered
‘dynamic’ because the number of rows
will vary from test case to test case. Line
39 in Figure 2 calls the QueryTestStepData
stub to get the dynamic data from the data
store.
Step 7. Insert rows in the dynamic
data report table
Since a variable number of rows exist
for dynamic data, the template file cannot
be created with a predefined numbers of
rows in its second table. For this reason,
the template file only begins with 2 rows
in the second table, which means the
export script is responsible for expanding
this table based on the data extracted from
December 2010
the data store. Lines 42 and 43 access
the second table in the report document
and insert rows (using the InsertRows
method) in the table based on the data
obtained from the data store.
Steps 8. Add dynamic data to report
Adding the dynamic data to the report
is similar to adding the header data,
except for the fact that the table cells in
which data will be entered have been
Automation Supercharged
(Continued from page 27)
tools also allow the test engineer to take a
snapshot of the AUT state and attach it to
a defect report to help the developers in
the debugging process. The functionality
provided by the VM management and
test management tool integration can
greatly reduce the amount of time
required for building test environments,
and can provide some added value to
the development team by enabling the
test engineer to send more detailed
information about a failed test in much
less time.
The use of virtual machines also
reduces testing’s footprint and costs,
allowing funds previously allocated
December 2010 www.automatedtestinginstitute.com
generated dynamically. For this reason, a
loop must be set up for entering the data,
C
as illustrated in lines 46 through 52.
Steps 9. Save and Close template ontribute
C
The final step in the process is to
ontent
close and save the generated report file.
Line 55 uses the saveas method to save
the file with a desired file name. Lines
T
58 through 60 close Word and do some
oday
variable cleanup.
for multiple AUT servers to be used to
advance other testing objectives.
Community
Closing Comments Box
There are many factors to take into
account when fine tuning your automation
effort, including environment, available
resources, and the track time that you Announcements &
are looking to meet or beat. All of the Blog Posts
methods mentioned above may not apply
to your particular scenario, but you can
take bits and pieces of this information
to fine tune your effort to increase its
performance, reliability, agility, speed,
and horsepower! Automation
Events
As a registered user you
can submit content directly
to the site, providing you
with content control and
the ability to network with
like minded individuals.
Learn more today
at
http//www.about.automatedtestinginstitute.com
Automated Software Testing Magazine 11
Open Sourcery
Ajar Source
It’s Free...For a Fee
Ah, open source software is great!
Let’s take a moment to list what we love
about it:
• It has a large community of
developers supporting it
• It offers users the ability to
customize it
• It is free
Wait a minute. The above list needs to be
amended:
• It has large community of
developers supporting it
• It offers users the ability to
customize it
• It is free
That’s right, open source software is
not always free. Just in case you were
wondering, this is not some thinly veiled
reference to the costs associated with
open source documentation and expertise
or the lack there-of. Open source software
is literally not always free. Believe it or
not, ‘Totally Free’ is not a prerequisite for
software to be considered open source, and
many companies are taking that loophole
to the bank… literally. Take Redhat for
“Free software” is a matter of liberty, not price. To understand the
concept, you should think of “free” as in “free speech,” not as in “free
beer.”
example. Redhat, whose leading product
is Red Hat Enterprise Linux, is an open
source company that is expected to reach
1 Billion dollars in software revenues
in 2011. A Billion dollars!? How do
you make a billion on open source? By
making it commercial open source, that’s
how. The concept of commercial open
source software (COSS) involves the
release of software that is in part free of
charge and open to the public, but has
some portions that are only available for
a fee and are often even closed source.
This type of business model has sparked
12 Automated Software Testing Magazine
a lot of debate, regarding whether these
products are really and truly open source.
It is argued by many that they are not,
and that the companies are merely
using the “open source” moniker as a
marketing strategy for software that is
in reality commercial. ZDnet has an
article entitled, “Commericial open
source, a misnomer”, that is all about
one man’s disdain for the intersection
of commercial and open source (http://
www.zdnet.com/blog/btl/commercial-
open-source-a-misnomer/1787). In this
article, a disgruntled patron of open
source products contacts SugarCRM, a
commercial open source company, via
email and states:
“I don’t get it. You say that
SugarCRM is open source
however the latest version (3.5)
of the open source version still
doesn’t have the ability to group
www.automatedtestinginstitute.com
people (or as you call it teams).
Now your Pro version has had the
ability to do teaming since at least
version 2.0. I can’t help but think
that this being a critical function
of a CRM system is intentionally
left out in order to steer people
to the commercial version of you
product. Am I wrong here?”
Many feel duped by commercial open
source products, because they are of the
opinion that the “open source” portion of
the software is really not useful without
the features offered in the commercial
extension of the product.
Others say commercial open source
producers absolutely have the right to
sell certain portions of their software
to the public while remaining under the
umbrella that is open source. Those that
fall on this side of the fence often lean
on the Free Software Definition, which is
sometimes linked to open source and open
source licenses. This definition reads that:
“Free software” is a matter of
liberty, not price. To understand
the concept, you should think of
“free” as in “free speech,” not as in
“free beer.” (http://www.gnu.org/
philosophy/free-sw.html)
As the debate rages on, some are
appeased by the use of the terms, “free open
source software” (FOSS) and commercial
open source software (COSS), but many
are still angered that “open source” is used
at all in a commercial product’s name.
Since they’re only partially open, maybe
commercial open source tools should be
called “ajar source”. Maybe that would
quiet the debate.
December 2010
 Migrate your test lab
to the Amazon cloud
TODAY

December 2010 www.capcal.com

www.automatedtestinginstitute.com Automated Software Testing Magazine 13
14 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 15
TechnicaL
vs
Non- Technical
Skills in Test Automation

By DorothyGraham

‘T echnical’ & ‘Non-Technical’ skills

are the Yin & Yang of the test

automation discipline
16 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
S
eemingly at odds, both these interconnected skillsets
T

Technical

ec
hnical
are necessary for the successful implementation of

a test automation effort.

n-
No

this article, I d i s c u s s t h e r o l e , of the testers and test automators

In in test automation. Technical skills are needed by test automators, but testers who do

not have technical skills should not thereby be prohibited from writing and running automated tests.

TestAutomationSkills
Existing Perception
The automation of test execution
is a popular application of computer
technology to itself. There are a number
of books about test automation. Many
of them do not appear to mention skills
needed (or it was not obvious if they
did). There is a general perception that
testers must be or become technical,
i.e. programmers, if they are to become
involved in automation, although there are
a few exceptions that mention a distinction
between testers and automators.
Linda Hayes in her useful booklet
on automation says: “… developing
test scripts is essentially a form of
programming; for this role, a more
technical background is needed.”
(Hayes, L. G. 1995. Automated Testing
Handbook. Software Testing Institute,
Dallas, TX.) She distinguishes between
“Test Developers” i.e. testers, and “Script
Developers”, which is part of the role of a
test automator.
Dustin et al says: “When people think
of AST [Automated Software Testing],
they often think the skill set required is
one of a ‘tester’, and that any manual
tester can pick up and learn how to use
an automated testing tool. Although the
skills [of a tester] … are still needed to
implement AST, a complement of skills
similar to the broad range of skill sets
needed to develop the software product
itself is needed.” (Dustin, E., Garrett,
T. and Gauf, B. 2009. Implementing
Automated Software Testing. Addison
Wesley/Pearson Education, Boston, MA.
p 225)
A paper by Mosaic mentions
three roles: “Manual Test Engineer”,
“Automation Test Engineer” and “Lead
Automator” ([author unknown] 2002.
Staffing your test automation team.
Mosaic Inc, Chicago IL. http://www.
mosaicinc.com/mosaicinc/successful_
test.htm). In this model, the design of
tests (i.e. the tester’s role) is done by both
test engineers; the automation work (i.e.
test automator’s role) is done by the lead
automator and automation test engineer.
The key distinction is who designs the
tests, which in my view is best done by
the tester, but collaborating with the
test automator for tests that are to be
automated.
Is test automation a technical
task?
The answer to this question depends
on what you include as part of “test
automation”. If you view it as the direct
use of a test execution tool, i.e. writing,
editing and running scripts written in
the tool’s scripting language, then it is
a technical task, and programming (i.e.
scripting) skills are needed.
Another technical aspect of test
automation is the design of the testware
architecture – the structure and relationship
of all of the items of testware that comprise
the artifacts required for automated tests
to successfully run. The design of the
testware architecture is a critical aspect
for successful test automation, and the
skills needed for this include technical
expertise, as well as knowledge of how
the tests are to be used. The person who
designs the testware architecture may be
called a test automator, test architect, or
lead automator.
Constructing automated tests
is not entirely a technical
process
The construction of the automation

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 17

 scripting language. One tester decided he

K ey
didn’t want to become technical, so he
concentrated on manual testing, but the
others all became good test automators.

T erminology
There were two interesting side-effects of
the testers’ newly acquired skill set. First,
they had a lot more sympathy for the
developers, as they now understood first-
hand the frustrations of trying to get the
• Test automation: the computer-assisted running of soft- computer to do what you wanted it to do.
ware tests, i.e. the automation of test execution. Second, they found that the developers
treated them with a bit more respect, as
• Test automator: A person who builds and maintains the they now also had some development
testware associated with automated tests. skills. This led to a better relationship
between the developers and testers.
• Tester: A person who identifies test conditions, designs Another example where it worked
test cases and verifies test results. A tester may also very well to have all of the testers become
build and execute tests and compare test results. automators is described in a chapter by
Lisa Crispin in our forthcoming book
• Testware: The artifacts required to plan, design and ex- (Crispin, L. Zero to 100% Regression
ecute tests, such as documentation, scripts, inputs, ex- Test Automation in one year: an Agile
Approach to Automation 2010. In
pected outcomes, set-up and clean-up procedures, files, Graham, D. and Fewster, M. Experiences
databases, environments, and any additional software of Test Automation. [Publisher not yet
or utilities used in testing. determined]). An agile team of 9 to
12 people were all involved in doing
manual regression testing, so were highly
motivated to automate 20% of their work,
architecture, and the scripts and other determined, but this is a task that is done and everyone became involved in the
testware that will be used to run automated by a tester; the implementation of the test automation.
tests is a technical task, but automated is what is done by the automator.
testing is not just the structure of the
architecture and scripts. A separate team of test
TestersToAutomators? automators?
The whole purpose of test automation
is to make it possible to run tests with I have seen other organizations where
minimal human involvement in test Testers become automators? a separate team is set up to automate tests,
execution (and comparison). leaving the testers free to concentrate on
I have seen it work well to have a designing tests and running manual tests.
There is a need for testers to be able team of manual testers embarking on an As the automation team gets going, they
to use automated tests, both to write tests automation project, where all (or nearly automate tests nominated by the testers,
to be run automatically, and to run those all) of the testers effectively become freeing the testers from having to do
tests and view the results. The tests that programmers, i.e. test programmers, those tests manually. The automation
are to be automated could be technical
team provides
tests, such as
a service to the
those written
by developers The content of the test needs to be testers, designing
the testware
as part of
Te s t - D r i v e ndetermined, but this is a task that is done by architecture and
structure of the
Development or
unit or integration a tester; the implementation of the test tests, and assisting
where needed
testing,
system
but
and is what is done by the automator when problems are
encountered with
acceptance tests
the automated
can also be automated, and the testers who or scripters. At a former colleague’s tests. For example, if an automated test
write those tests are not always technical company, five out of the team of six fails, it could be because of a software
(i.e. software developers). testers went on the tool vendor’s training fault (in which case the tester would
The content of the test needs to be course and became familiar with the tool’s have found a bug), but it could fail for a

18 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

Are You Contributing
Content Yet?
The Automated Testing Institute relies heavily on the automated testing
community in order to deliver up-to-date and relevant content. That’s why
we’ve made it even easier for you to contribute content directly to the ATI
Online Reference! Register and let your voice be heard today!

As a registered user you can submit content directly to the site, providing you with
content control and the ability to network with like minded individuals.
Community
Comments Box >> Community Comments Box - This comments box, available on the home page of
the site, provides an opportunity for users to post micro comments in real time.
>> Announcements & Blog Posts - If you have interesting tool announcements, or
you have a concept that you’d like to blog about, submit a post directly to the ATI
Announcements & Online Reference today. At ATI, you have a community of individuals that would love
Blog Posts to hear what you have to say. Your site profile will include a list of your submitted
articles.
>> Automation Events - Do you know about a cool automated testing meetup,
webinar or conference? Let the rest of us know about it by posting it on the ATI site.
Automation Add the date, time and venue so people will know where to go and when to be there.
Events
Learn more today at http//www.about.automatedtestinginstitute.com
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 19
technical reason such as a problem with
the environment, a missing testware item
(i.e. a bug in the automated testware), or
a problem with the tool itself. The tester,
not being technical, will need technical
assistance to identify the source of the
problem.
So we have the situation where test
automation does require technical skills,
but we have testers who do not have those
skills – can this really work? Yes it can,
but it needs two key separations or layers
of abstraction.
AutomationSuccessNeeds
LayersOfAbstration
Technical Layer
Technical aspects are very important
for test automation. A good testware
architecture will implement good software
The skills of the tester and the skills
of the test automator may be found in the
same person, but it may work better
to have different people performing the
two roles.
development practices for the testware,
separating the tool itself and the direct
scripting of the tool from the software or
scriptware that calls and uses the lower
level scripts. Modularity and reuse are
key factors in minimizing maintenance of
automated testware. If something changes
in the software, the testware will need to
reflect that change. With lower levels of
scripting (a recorded test or linear script
being the lowest), a small change to a
screen can result in making “magnetic
trash” of the automated tests (Kaner, C.,
Falk, J. and Nguyen, H. Q. 1993. Testing
Computer Software. Van Nostrand
Reinhold, NY.).
If possible, the testware should be
designed so that it can cope with changes
in the software under test without needing
any changes to the testware. If this is
not possible, the effects of any change
20 Automated Software Testing Magazine
to the software being tested should be
confined to only one testware artifact (or a
minimum number if this is not practical).
This layer gives good maintainability
to the automated test regime.
Tester Layer
If all of the testers are technical,
such as developers who are doing Test-
Driven Design or unit testing, then this
layer is not as critical. The Tester layer of
abstraction is needed when system testers
or user acceptance testers want to use test
automation, but do not want to become
technical.
In order to achieve this, the non-
technical testers must be able to both write
tests (that can then be run automatically)
and also to run tests, i.e. to “kick off” a set
of automated tests.
If the testware architecture uses a
keyword-driven approach, the testers
can write tests using keywords that are
related to the business knowledge or
domain knowledge that they are familiar
with. Yes, they do have to follow the
correct syntax for the keywords, but tools
enable this to be relatively easy to do, for
example by providing a drop-down list of
valid keywords and checking the syntax
of parameters entered to the keywords.
The keywords are implemented (i.e.
programmed) by test automators, using
the scripting language of the tool, or using
any other programming language that
they know and is appropriate. The testers
are not involved in the implementation
of the keywords, but they are able to use
them to write tests.
The testers also need to be able to
select a set of tests to be run automatically.
This can be implemented by the test
www.automatedtestinginstitute.com
automators to make it easy for the testers
to kick off a set of tests, for example
by providing options in a user-friend
interface to the automation.
The testers also need to receive and
understand the results of the automated
tests, and the way in which this information
is communicated to them is also designed
by the test automator.
This separation of the tester from the
automation is needed for the automation
to grow within an organization and to give
long-lasting benefits and wide-spread
acceptance.
SummaryAndConclusion
Test automation does need technical
skill – for those who are closest to the tool
itself.
The skills of the tester and the skills
of the test automator may be found in the
same person, but it may work better to
have different people performing the two
roles.
The test automator’s role is critical in
establishing a modular and well-structured
testware architecture, separating the tool
from the testware, and providing a tester-
friendly interface to the testware for non-
technical testers.
Non-technical people can be good
testers; testers should be able to use test
automation without needing to have
technical skills. Getting to this point,
however, does require good technical
support.
Wait! There’s More!
This article is adapted from a white
paper written for the Conference of the
Association of Software Testing (CAST)
2010 held from August 2 - 4.
Also, for more information on technical
and non-technical test automation skills,
visit the Automation Body of Knowledge
(ABOK) portion of the ATI Online
Reference Site:
http://www.abok.automatedtestinginstitute.com
December 2010
2nd Annual

ATI Automation
Honors
Celebrating Excellence in the
Discipline of Software Test
Automation

See The Winners Now!

www.atihonors.automatedtestinginstitute.com

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 21

 Verify/ATI Con
Venture Beyond the Abstract

Call for Papers Opening Soon. Visit Conference Site

For More Information

www.veri
22 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
nference 2011

Save The Date!

September 19 - 21, 2011
Arlington, VA
The Test Automation Conference You’ve Been Waiting For

ifyati.com
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 23
Automation
Superch
By J.L. Perlin

Just like many auto enthusiasts “mod-

out” their muscle cars – you also
have the option to invest some time
and effort to get much more out of
your “auto”mation investment as
compared to the vanilla production
model which was designed for your
average driver, but doesn’t satisfy the
needs of all auto enthusiasts.

24 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

 Automation Supercharged

B
y implementing the

harged
techniques discussed in
this article you will be
able to reduce the amount of
time required to perform standard
automation tasks, expand the availability
of various testing resources, increase
environmental agility, and fine tune your
research and evaluation efforts. Some of the
methods that allow you to supercharge your
automation effort not only increase performance
for the testing team, but for other project teams, as well.

Do You Have Enough Horsepower?

It is important to consider the hardware that

your testing tools are installed on to ensure that you
are using the right engine for the job at hand. For
example, you wouldn’t want to enter a high speed
race with a low-output 2.0 liter engine. You’d want
to use the most powerful engine that your budget
will allow for. The same goes for the equipment
that you will be using for automated test design,
execution, and management. You want to ensure
that you have speedy processors with plenty of
memory to run on.

It is best practice to look at the minimum

hardware requirements for each tool you are using
(or plan on using) and exceed these minimum
requirements by as much as your budget will
allow. While minimum requirements are what
you will need to get the tools running, they are not
necessarily what you will need to make these tools
perform at an optimal level. Faster processors will
allow your tests to run much more quickly than if
they were to be executed using the processor speed
specified as a minimum requirement.

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 25

 Undiagnosed memory leaks are a common
culprit when it comes to test execution speed
degradation
Performance Tuning for
Speed & Efficiency
Increasing the speed in which your
testing environment resources deploy
and execute is one way that you can
supercharge your “auto”mation.
Multiple Workstations
An effective mechanism for
drastically reducing the amount of time
required to execute your automated test
suites is employing several workstations
to run your tests in parallel. Instead of
running your test scripts serially on one
workstation (which depending on the size
of your test suite may take many hours,
days or even weeks) you can break up
your test suite into segments and execute
each segment simultaneously on separate
workstations. Using two workstations
will cut execution time in half, so you
can imagine the time that can potentially
be saved through the use of several
workstations! These do not need to be
dedicated workstations. If the automation
tool is installed on machines that are
normally used for manual testing it does
not preclude them from being used off-
hours while the manual test engineers are
not in the office.
In addition to saving time during test
execution, time can also be used more
efficiently if each automation
engineer is supplied
two or
more
26 Automated Software Testing Magazine
workstations and monitors, along with
a Keyboard, Video and Mouse (KVM)
switch – hardware device that allows a user
to control multiple computers from a single
keyboard, video monitor and mouse – on
which to work during test development
and analysis. Typically, while automated
test are being executed on an automation
engineer’s workstation is unavailable
for use in any other capacity; therefore,
the use of a ‘KVM switch configuration’
will allow the automation engineers to
perform other automation tasks (scripting,
debugging, maintenance, etc.) on one
workstation while executing tests on the
other. In many cases this will also offer
test engineers the ability to analyze test
results during a test run instead of waiting
for automated test execution to complete.
For example, an automation engineer
might kick-off a suite of automated tests
on one workstation, and then click the
KVM switch to move focus to another
workstation that is used to analyze the
results of completed tests while other tests
in the suite are still running. This allows
the engineer to get a head start on test
results analysis rather than being forced to
wait for the completion of the entire test
suite.
Tool Settings
Test execution is often slowed by test
automation tool settings. For example,
many test tools allow users control over
the scope of test execution runtime
logging. As the level of test execution
runtime logging increases to capture more
information, the speed at which the tests
run may severely decrease. For example,
some tools give the user the option of
recording still images or a movie of a test
as its being executed. This “movie” may
www.automatedtestinginstitute.com
be a valuable item for demonstrating to
developers the exact steps that produce
an error (as well as illustrating the
error itself, but the process of recording
this information causes the tool to do
more processing, thereby slowing test
execution.
Along with indirectly changing the
speed of execution, some tools allow you
to choose a run mode that directly changes
the speed in which a test is executed. This
is often used for script debugging because
it makes it easier to follow the code as it
is being executed. The ability to follow
the code allows test engineers the ability
to more easily pinpoint the source of a
problem in the script. To increase script
performance it is best practice to ensure
that the scripts are running in “Fast” mode
during formal test execution. Many tools
automatically switch to “Fast” mode when
tests are executed as a part of a larger test
suite.
Coding Techniques
Coding techniques can also speed up
test execution, because some procedural
coding and runtime data gathering
techniques are more efficient than others.
One notorious culprit when it comes
to slowing down test execution is the
hard-coded “Wait” statement. These
“Wait” statements are holdovers from
older automated tool approaches that are
intended to allow the AUT to reach a
specific state or complete a process before
the automated test moves on to the next
statement in the test. This can present
many problems during test execution. The
first problem is that the Application Under
Test (AUT) may fail to complete the
intended process during the time specified
December 2010

in the Wait statement. The automated test
then tries to execute the step following
the “Wait” statement, and fails, because
the AUT is not ready for this step to be
executed. Or conversely, the application
may have completed its action in much
less time than allocated in the “Wait”
statement, forcing the script to wait longer
than is necessary before moving on to
the next step. These unnecessary pauses
can add up to a considerable amount of
wasted time when executing many tests.
When possible, it is best to use alternative
methods to have the test script sync with
the AUT. One solution is to identify an
The use of virtual machines also reduces
testing’s footprint and costs
object whose state will change when the
application is ready for the next step to
execute. For example, you may have a
test step that requires a button to become
enabled before the step can execute
successfully. Replacing a standard “Wait”
statement with code that instead monitors
a specific property of an object (in this
case, the “Enabled” property) and doesn’t
move forward until that property reaches
a certain value (“Enabled” = True) helps
to drastically increase the speed with
which your tests can be executed.
Code and Memory Cleanup
Another potential impact on test
execution speed to keep an eye on is
the creation and disposal of objects and
variables. Objects and variables are often
created and used by scripts, but are ignored
after they are used. If these objects and
variables are not disposed of after the test
that uses them completes execution they
will continue to use valuable resources
thus inevitably slowing test execution. It
is best practice to ensure that all objects
instantiated during test execution as well
as any variables declared and utilized, be
disposed of at the conclusion of the test.
Some testing tools provide utilities
that can be used to “clean up” the script
December 2010 www.automatedtestinginstitute.com
code, making it easier to manage and
increase performance. When available it
may be good practice to make use of this
built-in functionality.
Speaking of memory, undiagnosed
memory leaks are a common culprit
when it comes to test execution speed
degradation. Some automated testing
tools (and in many cases the AUTs
themselves) have undetected memory
leaks. As each test opens, executes, and
closes the effect of the memory leak(s)
compounds – eventually slowing test
execution to a crawl, or in many cases
crashing the automated testing tool or the
AUT. Many test engineers insert code
into their automation frameworks that
closes and reopens the testing tool and
AUT at regularly scheduled intervals, but
depending of the amount of time required
to open and close these applications this
may not be a feasible approach. For
example, some frameworks close and
reopen the AUT after each test – but only
close and reopen the automated testing
tool itself after the completion of every 10
tests.
Another factor in test execution
speed may be the makeup of the testing
environment. For example, testing
resources that are located on your local
workstation will most likely load more
quickly than resources that have to be
pulled from other locations, such as a
shared file server. When designing your
automation environment this must be one
of the first things taken into consideration.
In many cases the ability to share testing
resources (tests, data, etc.) across multipletools are able to integrate with the
testing tool installations via a centralized
repository may result in a negative impact
on test performance. But the decrease in
speed may be worth the trade off of being
able to share/reuse valuable resources
across several workstations.
Automated Software Testing Magazine 27
Automation Supercharged
Increase Agility
A virtual machine is an efficient,
isolated duplicate of a real machine that
supports the implementation of multiple
complete configurations (including
operating systems, AUT versions, etc.) on
one single box. For example, you can have
a virtual server available in your testing
lab that has several different installations
of the AUT, each being a different version
and/or configuration (operating system,
database, etc.)
This allows your team to quickly
bring the desired version of the AUT
online for testing, rather than having
to maintain a different server for each
version/configuration – or worse, having
to build the AUT from scratch each time.
In very little time the test environment
systems administrator can deploy shared
multi-tier application environments.
Using the same concept, the
workstation that the test engineer uses
can be set up as a virtual machine that has
several different testing platforms ready
and available for use. For example, a
tester may need to access the AUT from
a client that is running several different
combinations of operating systems and
web browsers. These client configurations
can be set up before testing begins. Since
the workstation is operating as a virtual
machine, the tester now has the ability
to quickly and easily load any of the
required platform configurations on the
client machine.
Some automated test management
VM functionality by providing test
engineers the ability to control the AUT
configuration directly from the QA tool.
For example, a test set can be built that
automatically accesses a particular VM
AUT configuration when executed. Some
(Continued on page 11)
 By Dion Johnson

Showing Up n
Management’s
Radar
6 Inevitable Questions You Must Be Prepared
To Answer
28 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
 “Often, test automation begins as just a
notion”

I t may be a simple notion by a testing team is soaring, but it is flying under the radar because
the initial notion was never really developed into a
resource that either got a hold of a commercial plan for how exactly test automation would help the
test tool that the company shelved, or perhaps project. The sheer activity of scripting is enough to
downloaded an open source automated test tool. provide a feeling of progress, and so it continues,
Maybe it is a notion by upper-level management that with no questions asked. This low pressure work
began a contract environment can
year with an ...the initial notion was never really developed be enjoyable,
ample budget and often useful
that they are all into a plan for how exactly test automation for a fledgling
too eager to burn automated
on massive tool
would help the project. testing initiative,
license purchases, but don’t be
service contracts and training. However acted upon and lulled into thinking this is how it will remain forever.
by whom ever it is acted upon, this notion is typically Eventually the project budget will begin to wear thin,
the same in all cases; it is a vague conception of test or the development and testing efforts will begin to
automation benefiting the testing efforts of the project. experience increased pressures, and alas management’s
So this notion is typically brought to bear through radar will pick up on the test automation effort. When
tool acquisition and proof-of-concept scripting. The this happens, if you’re not prepared, your automation

6 Inevitable Questions
1. What is the development level of effort?

2. What is the maintenance level of effort on the existing scripts?

3. What is the return on investment by functional area?

4. How much time is saved on execution?

5. What types of reports are available?

6. Can you transition the running of some tests to a developer or administrator?

Table 1: 6 Questions You Must Be Prepared to Answer

proof-of-concept scripting, like an airplane on a
runway, results in the automation effort taking off into
the friendly skies of the project with increased script
development and maybe even the hiring of addition
resources to support that effort. The automated testing
effort will get shot out of the sky.
In order to remain airborne once you appear on
management’s radar, there are 6 questions that you
must be ready to provide answers to.

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 29

 Be sure to base maintenance estimates on historical
Question 1 data (how much time you’ve spent maintaining so
far when a new build comes in), but also be sure to
What is the development level of effort? stress the fact that automation maintenance is a factor
of build/application stability, and is therefore subject
Before management will allow you to continue to drastic fluctuations in both the positive or negative
developing new automated tests, they’ll want to know directions.
how much effort is involved. This is important for
making a determination of whether or not continued
script development is worth the effort, and it’s Question 3
important for being able to track progress. You don’t
want to be in a position where you have to quickly
begin pulling numbers out of thin air, so even if What is the return on investment by
management doesn’t initially care about this, you
functional area?
should begin collecting metrics and developing your
own algorithm. A good place to start is by using a Return On Investment (ROI) is probably the top
commonly accepted industry standard for automation concern on the minds of management. It may be
development calculations. This standard indicates that difficult or rather impossible to calculate the ROI in
it takes anywhere from 3 to 10 times longer to automate terms of dollars saved, particularly if you aren’t privy
a test than it does to execute it once manually. The 3 to to the salaries paid to resources on the team. What you
10 range is normally determined by the stability of the can do, however is calculate the ROI in terms of man-
environment, structure of the automation framework, hours, and present this information to management.
and complexity of the application under test. You may This will allow management the ability to convert
find in your particular environment that you have the man-hours to dollar figures. Be sure to calculate
to adjust this factor to make it higher or lower. I’ve the current ROI based on the automation work that
worked in an environment where the instability the has already been completed, along with setting up
builds forced us to use a factor of 20. It’s important an algorithm that will allow you to plug in planned
to recognize that the automation development level of future script development and execution numbers
effort calculation needs information about manual test and calculate the resulting future ROI. In addition,
execution. it is important to calculate the ROI not just of the
automation effort as a whole, but also by functional
area. This will be used to set automation priorities. If
Question 2 one functional area is yielding a high ROI, automation
may be focused in that area, while manual efforts are
more greatly focused on other areas of the application.
What is the maintenance level of effort Conversely, if a functional area is yielding a low ROI,
efforts may be focused on being able to increase the
on the existing scripts?
ROI in those areas.
As new software builds are presented for testing,
scripts need to be modified. This is often a result of
functionality changes, application errors that must be Question 4
more gracefully handled, and changes to AUT objects
and data. Maintenance can often be a significant time
guzzler, so management will want to know how much How much time is saved on execution?
time needs to be budgeted for maintaining existing
automated tests. New script development may be This is also an ROI matter, but it is listed separately
prioritized based on the amount of maintenance from the question above, because that ROI question
involved on existing scripts, and maybe even halted. often factors automation script development into the

30 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

 When operating under the radar, it’s easy to
fall into the trap of quickly developing scripts
that require a special touch for execution

equation. Sometimes, however, automation script

development is not of concern. For example, if you’ve
been under the radar developing scripts, that time is
in the past and is often considered inconsequential.
In addition, projects are notorious for having slow
periods and high pressure periods of activity. Script
development might take place during slow periods,
while script execution takes place during high
pressure periods of activity; therefore, management
may mainly be concerned with time saved on script
execution because it speaks to the ability to alleviate
pressure during periods of high activity. For this
reason, it’s important to be able to point out how
much time is saved in script execution. This should
also factor in estimates for results analysis, because
the execution results will ultimately not be reported
until the analysis is completed. This metric need not
include analysis that would be done whether executed
manually or via automation. The analysis should
mainly factor in the time it takes to determine whether
issues are due to script failures or application failures.
Question 5
Question 6
Can you transition the running of some
tests to a developer or administrator?
When operating under the radar, it’s easy to fall into
the trap of quickly developing scripts that require a
special touch for execution; meaning, it is easily
executed and analyzed by you, but not intuitive
enough to allow someone else to execute and assess
what’s going on. If management is going to continue
to allow you to develop new scripts, however, they
may want to transfer some of the script execution
duties directly to software developers that might
more quickly benefit from being able to execute the
scripts themselves following code changes. Or, they
may want to transfer some of the script execution
to system admininstrators that might want to check
the system stability on a regular basis or after patch
installs. Therefore, the scripts should be developed in
a way that facilitates this, and a simple user’s guide
should be created that can be used by those that are
new to executing the scripts.

What types of reports are available? Conclusion

Reporting is very important for low level functional

analysis as well as high-level analysis of a functional While there is often good reason for staying under the
area as a whole. For this reason, it’s important to radar as long as possible, it is important to operate
convey the existence of the two different types of with the assumption that you are fully visible. This
reports. can be accomplished by making sure you are prepared
A high-level report that can be used to glean overall to answer these six questions at a moment’s notice.
application behavior, and a low-level log that can be If not, you run the risk of popping up on the radar
used for gaining details about each individual test and directly in the crosshairs of a management team that
each check within a test. is ready to shoot first and ask questions later.

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 31

32 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 33
I ‘B’Log To U

Latest From the B

Automation blogs are one of the greatest sources
to-date test automation information, so the Autom
Testing Institute has decided to keep you up-to-d
some of the latest blog posts from around the we
interesting posts, and keep an eye out, because y
your post will be spotlighted.
Blog Name: Gabor Szabo Blog Blog Name: Test Obsessed
Post Date: December 2, 2010 Post Date: October 20, 2010
Post Title: The Problem with Open Source is that
Post Title: Do Testers Have to Write Code?
you can’t blame it on Microsoft
Author: Elisabeth Hendrickson
Author: Gabor Szabo

In the propriatery world if you For years, whenever someone asked

encounter some issue and contact the me if I thought testers had to know how
vendor. A polite tier-1 support person will
to write code, I’ve responded: “Of course
tell you the issue is logged and will be
dealt with. Your part is done. You can keep not.” The way I see it, test automation is
blaming them of not having a solution inherently a programming activity. Anyone
yet. In the open source world they will tell
tasked with automating tests should know
you to upgrade. They can easily do that
as in most cases it does not cost you how to program. But not all
any money to get the latest version and testers are doing test automation.
install it. So your work is not
over yet. This is frustrating.

Read More at: Read More at:

http://szabgab.com/blog/2010/12/the-problem-with-open-sourcei-is- http://testobsessed.com/2010/10/20/testers-code/
that-you-cant-blame-it-on-microsoft.html

34 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

Blogosphere
s of up-
mated
date with
eb. Read below for some
you never know when

Blog Name: Automated Testing and QA Blog Name: DevelopSense

Post Date: September 5, 2010 Post Date: September 22, 2010
Post Title: Fortunate Test Automation Post Title: Can Exploratory Testing Be Automated?
Author: Peter Kartashov Author: Michael Bolton

In fact, people like and want real Machines can do checking, but they can’t do
cases, they want to hear that you or testing, because they’re missing the ability
whoever else did the same to evaluate. Here, I don’t mean “evaluation”
for some of “Fortune 100” in the sense of performing a calculation
companies. Moreover they want to and setting a bit. I mean evaluation in the
know how, why and for how
sense of making a determination about what
much they had got that. Your
people value; what they might choose or
potential Clients want to
know risks, issues, lessons prefer. In the second way of interpreting the
learnt and benefits of your question, automating exploratory testing is
proposal from other guys who impossible—but using automation as part of
had got the experience. an exploratory process is entirely possible

Read More at: Read More at:

http://at4qa.blogspot.com/ http://www.developsense.com/blog/2010/09/can-exploratory-testing-
be-automated/

December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 35

 Verify/ATI Con
Venture Beyond the Abstract

Call for Papers Opening Soon. Visit Conference Site

For More Information

www.veri
36 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010
nference 2011

Save The Date!

September 19 - 21, 2011
Arlington, VA
The Test Automation Conference You’ve Been Waiting For

ifyati.com
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 37
Hot Topics in Automation

QC/QTP Parameters Are Hot!

“Passing Parameters From Quality Center To QTP” Tutorial

Hewlett Packard’s Test Director for

Quality Center (also known as just
Quality Center) test management
solution and its QuickTest Professional
(QTP) functional automated test tool
is no stranger to attention. Some
people love these tools, some people
hate them, but few automators
are on the fence with no opinion.
However you feel about them, they
(together with LoadRunner) are the
juggernauts of the test automation
discipline. Thus, this may explain part I liked this video as it includes clarity of con-
of the reason ATI’s tutorial entitled, cept, good presentation, simplest way to pres-
“Passing Parameters From Quality ent to the end users. I would appreciate if more Username
Center to QuickTest Professional” video are available in other topics as well. upasana090
is so popular. Conducted by Dion
Johnson, this tutorial is offered free
to registered members of the ATI
Online Reference site and provides Wow this presentation had much power in it.
instruction on how parameters may any [viewer] can understand it clearly..please post
Username
be passed from Quality Center (QC) shivagc some more on it
to QuickTest Professional (QTP).
Passing parameters is one of the most
important concepts in test automation, This is one of the best video tutorial[s], that
so users of the popular HP test tools makes it so simple to understand, please provide
seem to appreciate the coverage of more video on QC (converting manual test to Username
this topic in an easily understandable automate) and QTP. ashly_2010
manner. This article includes what
some of say about the tutorial.
We thank you all for your feedback.
Since you are all requesting more, ATI Hi, you rocked man. This is one of the best
is scheduling new free tutorials to be Username
presentation[s] i have seen. Keep it up.
Testers5
released in 2011. In addition, be on the
lookout for special live training and
presentations at the Verify/ATI 2011 Bravo!! very nicely [presented]...good work..
Conference scheduled for September cheers! I am doing automation consultancy and
19 through the 22 (http://www. this is one of the area I want them to leverage... Username
verifyati.com). love this rajgarg

38 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010

 http://www.googleautomation.com
December 2010 www.automatedtestinginstitute.com Automated Software Testing Magazine 39
 Verify/ATI Conference 2011
Venture Beyond the Abstract

Save The Date!

September 19 - 21, 2011
Arlington, VA

The Test Automation Conference You’ve Been Waiting For

Call for Papers Opening Soon. Visit Conference Site For More Information

www.verifyati.com
40 Automated Software Testing Magazine www.automatedtestinginstitute.com December 2010