Commercial in Confidence

Developer Support For

Automated Testing

Synopsis
This document outlines high level requirements and
processes that can be implemented by development
teams in order to aid in the efficiency and
effectiveness of automated testing activities.

For further information relating to this document,

please contact James Alevizos on +44 (0)7979 655
477.

Version 0.2
Issued 11/04/06
Owner James Alevizos
Author Andrew Newton
Status Draft

© Vizuri Limited 2006

 Commercial in Confidence

Table of Contents

1 Executive Summary .......................................................................................................3

1.1 Change History .......................................................................................................4
1.2 Approvals ...............................................................................................................4
2 Introduction ...................................................................................................................5
3 Naming Conventions ......................................................................................................6
3.1 Standard Name Formats.........................................................................................6
3.2 Named Location / Navigation by Control ...............................................................7
3.3 Control Type ..........................................................................................................8
3.4 Release Notes and Processes .................................................................................9
4 Conclusion ...................................................................................................................10
5 Contact Details ............................................................................................................11

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 2 of 11
 Commercial in Confidence

1 Executive Summary

Early agreement between development and test can ensure that barriers to effective
automated testing can be avoided.

Automated testing can be hindered by minor issues, whether that is through a lack of
process, understanding or precision within development teams. Simple processes can be
implemented that counteract these issues and improve the returns on any investment in
automated testing techniques.

Basic rules, naming conventions and location naming can aid in the development of
applications from both a software development and testing point of view.

These include using names

or abbreviations that easily distinguish components

hat can be easily repeated
that are not prone to misspelling
that are as short as possible
that can locate components
that denote some degree of navigation

In addition, release notes can be used to communicate changes and new processes
between development and test teams.

Such processes are commonly carried out with development teams in the construction of
software throughout the software development lifecycle.

Minor alterations or considered changes can ensure that the automation process does not
falter when changes are made but flourishes and becomes integrated within the overall
development process.

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 3 of 11
 Commercial in Confidence

1.1 Change History

Version Reason Authors Date

0.1 Draft Issue Andrew Newton 29/03/06

Minor additions following internal
0.2 James Alevizos 10/04/06
review

1.2 Approvals
This document has been approved by:

Name Organisation Role Date Version

James Alevizos Vizuri Ltd Director 10/04/06 0.2

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 4 of 11
 Commercial in Confidence

2 Introduction
The latest test automation frameworks and tools make it possible to gain significant
benefits and returns-on-investment from automated software testing. However, projects
could make further savings in time and effort if the software design had the requirements
for automated testing built in.

Automated testers regularly deal with issues due to a lack of communication of simple
information between development, testing and automated testing teams. Very simple
changes in applications under test, implemented early in the development phase can make
the task of building and maintaining automated test frameworks much easier.

The average developer may make decisions on a project that inhibit automated testing
tool’s ability to work efficiently, effectively and robustly. New releases and builds can
hinder the usefulness of an automation tool if agreed guidelines have not been followed.
However, if development teams know about these guidelines they can often be
accommodated initially on new applicatoins and over time on existing applications.

There are processes that a development team can implement to provide support
throughout the automated testing process, which include many typical programming
conventions, including

Naming Conventions
 Standard Name Format
 Named Location
 Navigation By Control Name
Consistent Naming Of Infrastructure components
Design Consistency
Detailed Release Notes & Procedures

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 5 of 11
 Commercial in Confidence

3 Naming Conventions

Often the biggest obstacles to efficient test automation initiatives are either difficulties in
identifying the objects initially or frequent and inconsistent changes to object properties.
Examples include names to identify buttons, pages or input fields. Here, even the addition
of capitalisation or extra spaces can throw an automated tool into chaos.

The names of commands and objects are an important part of the usability of an
application. Likewise the names given to software components like variables, functions,
classes and commands are also an important consideration for automation tools. Choice of
names, whether made by the system's designers or by programmers themselves can affect
the ease with which an application is understood, recalled, readable, and maintainable
along with the way in which it is automated.

Automated test tools rely on the ability to locate and uniquely identify each window and
object of each application under test. This process is typically referred to as ‘object
identification’ and the tool provides a repository for these objects and their identifying
properties.

Thus, if automation is seen as an important facet of the whole testing process, the
following practices need to be incorporated within the software development lifecycle

standardise on object naming conventions early to reduce the likelihood of having

to change them in a later build
educate development in regards to the costs of changing object properties
ensure unique titles are used for different pages on a web page or different
windows in a standard application
include a distinct ‘name’ property to all table objects that require testing
ensure that where data is retrieved and displayed unmodified from a database, the
object should contain the column name of the original data.

3.1 Standard Name Formats

The goal of a name is to uniquely identify an oobject, whether that object is a window, a
page or a button. Names allows for the focus of discussions, e.g. a command that produces
an action, to be easily understood by those involved in the discussion.

Within software development design the most important element of a name is its
precision. Naming practices are generally designed to minimise ambiguity and reject
attempts to introduce names that are imprecise (or prone to imprecision). Such names
need to remain unique over the lifetime of an application and despite the introduction of
other pieces of code, which may be written by other developers.

This robustness can be achieved in a number of ways -

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 6 of 11
 Commercial in Confidence

In Java, developers are encouraged to prefix package and function names with
Organisational Names, i.e. when developing new functions:
com.YourCompany.Function.
Globally Unique Identifiers (GUID’s) – which use a combination of the computers
MAC address and the clock time
Case Distinctions – i.e. within Java string, String and STRING can each have a
different meaning
Hungarian Notation – which uses a set of short prefixes to encode the type of
variable in a name, i.e. IpszFirstName refers to long pointer to string terminated
by zero

The latter two notations refer to another important aspect of naming - suggestiveness.

Whether dealing with applications or automated testing we require other properties within
a name, to the extent that, a name can describe the content, use and type of the thing it
is identifying.

Error prevention is also desirable when developing naming conventions. Names that do not
readily lend themselves to repeated entry and re-entry, or can be easily misread need to
be avoided.

One way to counteract this is by the use of shorter names as opposed to longer ones, as
they are faster to read, enter and communicate between teams.

Finally, pronunciation though a relatively minor issue still has some significance. Both
developers and testers will often talk about the components of an application and difficult
names can inhibit this form of communication, especially where the acronyms or local
knowledge is not documented.

3.2 Named Location / Navigation by Control

Another difficulty with the naming of software components is that invariably the name
bares no relation to the location or how to navigate to that component.

Naming conventions that adopt such a principle can remove a major degree of ambiguity
from discussion, whether that is in how to test an application or the cause of a failure
within the application.

The table below highlights how such a convention would work

Root Button1 (RT01BN01)

(RT01) Button2 (RT01BN02)
Form1 (RT01FM01) Button1 (RT01FM01BN01)
Field1 (RT01FM01EX01)
Combo Box1 (RT01FM01CX01)
Form2 (RT01FM02) Button1 (RT01FM02BN01)
Field1 (RT01FM02EX01)
Combo Box1 (RT01FM02CX01)

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 7 of 11
 Commercial in Confidence

In this case, we have an application with a root base state (RT01). Within the top level
root of the application, we know that we have two main forms or windows (RT01FM01 &
RT01FM02) and two buttons which can perform certain set actions (RT01BN01 & RT01
BN02).

Within the two forms; we can see that they each contain a button (RT01FM01BN01), an
input field Field1 (RT01FM01EX01) and a combo box Combo1 (RT01FM01CX01).

The benefits of such a naming convention become apparent when we either have an issue
with a faulty component or need to concentrate testing on specific components.

For instance, if there was a defect outstanding with Combo Box 1 located with the second
form (RT01FM02CX01), the information contained within the description of the object
allows the development team to navigate to the object and make certain assumptions
about its behaviour. Discussion with business representatives and testers can then
concentrate on providing a clear and distinct resolution.

3.3 Control Type

Windows application development involves a number of set objects. Using this as a

guideline, a simple two letter abbreviation can be used to distinguish a wide range of
objects and denote their behaviour. This can then be expanded to include other types of
applications, whether windows or browser based.

In cases where more than one component exists within a form / window, these can be
distinguished by the components two digit tab indexes or the index instance of that object
type. You may have four components on a page, where object two and four are buttons. In
the first instance they would be distinguish as BN02 and BN04, whereas using the second
principle they would be distinguished as BN01 and BN02. A common agreement can ensure
that objects are distinguished appropriately.

Control Mnemonic
Form (Window) FM
Button BN
Edit Box / Test Box EX
Label LL
List Box LX
Combo Box CX
Menu MU
Context Menu CU
Check Box CB
Group Box GX
Picture Box PX
List View LW
Tree View TW
Tab Control / Tab Pane TL
Calendar Control (General) CL
Horizontal Scroll Bar HR
Vertical Scroll Bar VR
Numeric Spinner NR

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 8 of 11
 Commercial in Confidence

Progress Bar PR
Rich Text Box RX
Tool Bar TR
Open File OD
Save File SD
Directory Browse DD
Font Dialog FD
Colour Dialog CD
Print Dialog PD
Print Preview Dialog VD

Additional Rules

RT01 always refers to the top level form or application under test
Control names are constructed from the above named codes followed by a
numbered index
Control names not appearing in the list should be agreed with the testing team
prior to commencement of coding
Names of parent controls should be concatenated into their child control names in
order to provide a path back to the top level form, e.g. RT01FM01BN01 refers to a
button within the first form of the top level form/application

3.4 Release Notes and Processes

Accurate and detailed software release notes and consistent development processes can
allow the automation testing team to highlight key processes that may have a greater or
lesser impact on the efficiency and effectiveness of an automated testing strategy.

Release notes allow the automation team to know whether additional components have
been introduced to accommodate their introduction and consequently support to tailoring
of automated scripts to cope with such additions. In conjunction with the above naming
convention, new components can be easily integrated into an aspect of an application and
a degree of non-GUI process testing can take place in order to highlight any potential
conflicts early.

In addition, the documenting of software development processes can highlight issues that
may not have been explained or understood correctly. The documenting of both the
common development and automation processes can be a good source of discussion
between the teams and highlight constraints and issues that may be clear to each group
but difficult to communicate.

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 9 of 11
 Commercial in Confidence

4 Conclusion

Inefficiencies, rework and delays in the preparation and maintenance of automated

test scripts can easily be minimised. Proposed solutions detailed in this document
would require minimal effort and can be implemented at the outset of a development
project or during an existing development.

Individual projects differ, but there are common set of standard principles that can be
applied.

Gain input from the test automation team early. This should involve someone
who has a good knowledge of the test tool being used and a basic understanding
of the software architecture being tested.

Work with development to produce brief guidelines for building and maintaining
software to support automated testing initiatives, e.g. standardisation of object
identification properties, understanding the effects of changing properties
between builds etc.

Time spent between development and automated testing teams in agreeing a basic set of
principles and processes would ensure that automated testing scripts could be created and
maintained in line with application changes in the most efficient manner.

As result, an automated testing strategy could further accelerate the testing function,
increasing speed of testing, test coverage and an organisations return on any investment
made in automated testing techniques.

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 10 of 11
 Commercial in Confidence

5 Contact Details

Address Vizuri Limited

1-9 Memel Street
London
EC1Y OUT
Phone +44 (0)20 7014 8900
Fax +44 (0)20 7014 8901
Company Number 4268004
VAT Registration Number GB 782 3721 19
URL www.vizuri.co.uk

Solutions Director James Alevizos james.alevizos@vizuri.co.uk

Sales Director Derek Greene derek.greene@vizuri.co.uk
Chief Executive Officer Brian Shea brian.shea@vizuri.co.uk

Title Developer Support For Automated Testing v0.2.doc

Issued 11/04/2006
Owner Andrew Newton Page 11 of 11