4-Tier Architecture Of The Functional Test

Automation Framework
Pankaj Bhatte
Cognizant Technology Solution
Pune, India

1. Before The Framework - Evolution Of The Framework

Since the introduction of test-automation tools, last few years have seen a
change in the perspective of testers, managers and business analysts. The way
managers plan the regression testing, the expectations of business analysts and most
importantly the life of tester – all have significantly changed.

To start with, the creators of the automation tools marketed their products as the
make-a-wish-come-true software. Just launch our tool, click on record, navigate through
the application, stop recording and you’ve a script. This glossy image of automation
created a wrong impression about the overall test-automation discipline. Whenever it
comes to resource allocation or time slicing, automation is thought as a matter of couple
of clicks. The unfortunate consequence of this is generation of legacy scripts which are
not interpretable by third person, heavily dependent on the state of application as it was
while recording, thus pretty difficult to maintain. The first generation of scripters spent
quite a lot of their time redoing the same scripts for every new build – they kept on
reinventing the wheel. The scripts were necessarily independent of each other without
any code sharing. As a necessary next step in evolution, came the next generation of
smart-scripters. (Note here that scripter is slightly different than a tester. A scripter is a
tester with good development skills.) These smart-scripters attempted to solve this
problem of unnecessary repetitions by consolidating common functionality - like login -
into a separate script. Although this saved their efforts to some extent, there were plenty
of issues waiting to be addressed. UI widgets still needed special functionality. Things
like checking whether the search returned any results, whether an option is available in
dropdown box, were still repeated. These smart-scripters applied their development
experience here to come up with some generic functions like a function to get number of
rows in a table, check existence of a value in a dropdown box. These functions were a
handy repository and added reusability to the scripts.

Need is always the driving force and as they say - it is the ‘Mother of Invention’.
The script-development methodology proposed in this paper is the outcome of several
needs of the industry. In today’s typical regression testing scenario, requests for
automation scripts come in an ad hoc manner. In the total development life cycle,
significantly less resources and time is given to writing scripts for regression testing.
There is a strong need for some ‘Rapid Script Development’ methodology. I propose this
methodology which will not only help making quick scripts but also ensure good script-
mortality in long run and reduce chances of having to write an all new script by scraping
the old one. The suggested methodology termed as ‘The Automation Framework’ is an
attempt to satisfy the extreme needs of the industry at the same time adding value to the
overall discipline of test-automation.
2. What is The Framework - Conceptual Overview

The Framework is an attempt to simplify and speedup scripting by making use of

reusability. It starts with the idea given by new-generation smart-scripters: Do not
duplicate code – Refactor it! The Framework extends this concept to a higher altitude, it
says: Don’t keep refactoring as an optional exercise – Make it a rule. We also leave
behind the procedural approach of calling scripts and replace that with functional
approach – making functions with parameters. Before going into concepts, let’s try to
coin a simple definition for the Framework:

“The Framework is a tiered organization of the function libraries.”

We use the functions to ensure reusability. The next step is to organize these functions
into separate libraries, which help in keeping the functions more managed and
organized. We try to classify the functions into distinct categories. The way this
classification is done leads us to the concept of tiers. We don’t stop after pulling off a
common piece of code
and putting it into a
function. We actually go
a step further and try to
make it still more
granular. First we break
up the script into what we
call navigational steps.
Steps like login to an
application and perform a
search are examples of
navigational steps. For
each step there is a
function in a library called
Navigation Library. We
then try to break up
every function in the
Navigation library into
smaller steps. For example, login can be broken up into three steps: enter username,
enter password and click log in button. It’s now that we step one level down in
abstraction and reach an object level. In above example we will make two functions:
‘enter text in an edit box’ and ‘click a push button’. As one can see these functions are at
a different level of abstraction and hence are placed in a separate library in a separate
tier. This tier is called GUIObjectUtility. These object functions in turn make use of APIs
provided by the tool, which are very much tool-specific. These APIs thus form the fourth
and the lowermost tier of the Framework. This is how the concept of tiers comes into
play. These four tiers - The script (topmost tier), Navigation (second tier) and GUI object
utility (third tier) and tool-specific APIs (fourth tier) - are the basic building blocks of the
Framework and form the basic skeleton. These represent the primary libraries. Some
other libraries take care of other miscellaneous activities like handling test data, GUI
maps, working with database (if the scripts involve database validations) and working
with terminal emulators etc. All these and other libraries are categorized as the
secondary libraries.

2 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

3. How The Framework Works – Detailed Description
Now that we have basic overview of the Framework, let’s take a close look at
how everything is put in place. We are taking an example of a web-based application for
which we are writing scripts using WinRunner. To begin with there are no scripts, no
libraries and no GUI Maps.

The First Script

This is where it begins. Let’s
assume a sample Test Case.

Step 1: Record the script (Tier 1)

Do the recording as we traditionally
do. To briefly explain what’s
happening in there, the script starts
on the home page. First the user
enters username and password and
then clicks ‘Log in’ button. A search
page comes up. User selects
‘Product Number’ in search type drop
down. Enters a product number in the
search box and then he clicks
‘Search’ button. This brings a search-
result page on which there is a list of
products that match the search
criteria. The test is to verify whether
correct results are displayed.

Step 2: Break up the script into logical steps (Tier 1)

Now starts the process of building up
the Framework. First identify logical
steps in the script. For this we use
the Test Case as the guide. The
script in above example can be broken down into three blocks as shown. Note how this
maps to the Test Case verbatim.

Step 3: Mark these Steps as Functions in the Navigation Library (Tier 2)

Now split the script into these identified segments. Each segment will represent a
function in Navigation library. From the script we will call these functions. Make every
function using following steps
I. Decide the purpose of the function: First decide what is the function expected
to do. This purpose
should be evident from
the script break-up
exercise in previous
step. Let’s say for
example - “Log in to the
application using
username and
password.”

3 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

II. Decide name for the function: Using this purpose formulate a good name. It’s
recommended that because the function is supposed to ‘do’ something, it’s name
should start with a verb. In current example the name will be –
‘Log_In_To_Application’. Feel free to use common sense here.
III. Determine input parameters: Again look at the function purpose, and determine
what all data is required to accomplish this purpose. This gives us the list of input
parameters. For our Log in function the input parameters will be Username and
Password.
IV. Determine return values:
Not all, but some functions
do need to return a value.
For example we will make a
function for getting Product
name from results page.
This function returns text
signifying the product
name. So the return type is
string.
V. Implement the function:
Finally put all this info
together and create
function header. Get the
code from script and
implement these functions.

Step 4: Call these functions from the Script (Tier 1)

Now that we have these functions doing the job done by the recorded code in the script,
we can replace that code by calls to these functions. Once again, map this script to the
Test Case we started with. Notice how all the code has disappeared in the background
and we got a reader-friendly abstraction of the script.

Step 5: Modularize the Code in Navigational Functions (Tier 2)

We now turn our attention to the Navigation Library. Identify Steps in each function. Like
we used the Test Case for breaking
up the script, here we use the
operations on GUI Objects. Every
operation is treated as a separate step. Thus for example the Log in function can be
broken up into three separate steps as shown.

Step 6: Make these steps as functions in the GUIObjectUtility Library (Tier 3)

Each of these steps is an action taken on a GUI Object. So on Tier 3 make functions to
support all these
operations. Take this
opportunity to make
the wait times uniform.
Just declare one
common constant
(iWaitForWindow in
shown example) and use that everywhere. This gives us ability to globally vary the wait
times by changing one single value. The Function designs are made using the method
similar to the one in Step 3 above.

4 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

Step 7: Call these
functions from the
Navigation (Tier 2)
Now replace the
code in the function
in the Navigation
library by calls to
these newly written
functions in the
GUIObjectUtility.

Step 8: Create a Library for managing the Dynamic GUI Maps (Tier 4)
One of the important components of a WinRunner script is - the GUI Map. The functions
in the GUIObjectUtility Library will not work properly unless the required objects are
loaded into the
GUI map. The
approach that
we are going to
follow here is
called ‘Dynamic
GUI maps’. The
word dynamic
signifies that we
do not maintain
any pre-recorded
GUI maps.
Instead what is
done is, before
any operation on
an object, that
object is loaded
into the GUI
Map. After
the operation
is done we
remove its
entry from
GUI map,
keeping the
map clean.
To
accomplish
this create-
use-and-
destroy
method we
introduce the
4th tier called

5 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

GUIMapUtility. The functions in this library perform the operations of adding and
removing windows and objects into and from the GUI maps.

Step 9: Update GUIObjectUtility to wok with Dynamic GUI Maps (Tier 3)

As described in the previous step, now change the GUIObjectUtility so that GUI Map is
handled at run-time. In every function in GUIObjectUtility, first the GUI Map is empty.
The object and the window containing that object first need to be added to the GUI Map.
Next step is actually acting on the object like clicking a pushbutton, or entering a value in
a text box. Lastly we need to remove this object and window from the GUI map thus
making it empty again. This process is followed in all the GUIObjectUtility functions.

Step 10: Managing

Data
There is hardly any
test that has no test
data. So in our
scripts, we are
normally required to
do activities like read
a value from data
table, get the
number of rows in a
data table and save
a value to a data
table. For all such
tasks we make
generic routines and
keep them in a
secondary library
called the
DataTableUtility.

Step 11: Make the

script data-driven
Using the
functions in
the above
library, we
will make
our script data-driven. Typical candidates for parameterization in the script are
username, password, product number and expected product name. Make use of
DT_Read_A_Value_From_DataTable function, to get these values from data files.

Step 12: Final tasks: Compile and

execute
Finally we will compile all these
library files as compiled modules and
load them in the script using the load
function.

6 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

The Second Script

As one can easily notice, the first script took considerably more time and efforts than
normal. But one should also see this as not just writing a script but also building up a
function repository. Let’s see what happens when we create the second script.

Here is a Test Case for our second

script.
As one can see it is quite similar to the first
one. The only difference here is that we are required to search the product by the
product type instead of the product number. However, the steps for building up the script
are quite different than the first one.

Step 1: By referring existing scripts, create new script (Tier 1)

Life is much easier this time. We have many functions already in place and we can put
them to work. The script 2 will be almost similar to the script 1 except the fact that
instead of calling the function Search_Product_By_Product_Number, we will be calling a
new function Search_Product_By_Product_Type.

Step 2: Extend Navigation Library (Tier 2)

As one can easily figure out, next step is to implement this new function in Navigation.
Over here as well, we can refer to existing function to get the function skeleton. We are
assuming these steps for product search by product type. Select ‘Product Type’ in
search type dropdown. Then select some product type in the ‘Product type’ dropdown.

7 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

Finally click Search button. This function will be quite similar to the one for the search by
product number.

Step 3: Extend GUIObjectUtility (Tier 3)

We might need to extend the GUIObjectUtility Library. This happens when there is a
demand for an action on some new object that is not already taken care of. For example
if there is some step that requires clicking a checkbox, we will be needed to write a
function for that in the GUIObjectUtility. Also if we need to do some new action on
existing object, like clicking in editbox or checking whether a pushbutton is enabled, we
need to address this in the GUIObjectUtility.

Step 4: Extend GUIMapUtility (Tier 4)

If the Tier 3 is changed for some new object, we will have to make sure that we have
functions handling the dynamic GUI maps for that one as well. We will need the
functions to add/remove this object from GUI map.

The Subsequent Scripts

As can be seen, the second script took considerably less time compared to the first
one with hardly any recording. The whole process now becomes simple and matured.
For developing subsequent scripts we only need to repeat these four steps. In most of
the cases almost all the functions are already present in the repository. Reusability is the
basis of the Framework and one realizes it’s benefit better, when more and more scripts
are developed. Soon there comes a threshold point called the ‘object saturation’. This
signifies that all possible GUI Objects are taken care of and there is less than one
percent chance that one might need to do step 3 and 4 (extending Tier 3 and 4). This is
quite expected, as normally there are limited types of objects that need to be tackled.
Say for example in a web-based application there are only a few objects like buttons,
edit boxes, links, radio buttons, combo boxes, checkboxes etc. Sooner or later we are
bound to reach a point when we have coded for all these objects. This might happen
after 10 scripts for some application and 25 scripts for some other. It depends heavily on
type, size and complexity of the application and the choice of Test Cases for scripting.

Such a threshold comes quite late for the Navigation Library because of the fact that
the Navigation deals with business logic of the application, which can be far more
complicated and wide spread. Thus the Navigation keeps on growing as the script
development progresses. So we break up the Navigation into multiple library files based
on different areas of application. This helps us to keep function per file figure down, and
makes it more manageable. For the other Tiers normally one library file suffices.

8 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

4. Why The Framework - Advantages and Benefits
Business Propositions

1. Rapid Script Development

The primary
force driving
this concept is
the ease of
scripting. The
scripts can be
developed in a
rapid pace
using the
existing
functions.
Initially we
invest some
time and efforts
for building the
foundation and
then the
Framework behaves as a fast script creation warehouse. Making a script becomes a
matter of just referring the Test Case and calling functions in that particular order. The
graph for script development time against the script number illustrates this point better.

2. Readability
It provides different layers of abstraction for the reader and allows him to concentrate on
different aspects at different levels. It becomes very easy for him to map script to the
Test Case. Even the lower tier functions give a better organized and hence more
readable view of the script. This helps new members of the team to understand the
scripts faster, making the scripts easier to maintain. For people who are not conversant
with the scripting tool, the Tier 1 gives a less complicated and reader-friendly abstraction
of the script.

3. Smart Exception-handling
All the Test Cases are based on some assumptions and they take into consideration the
possibility of some exceptions. There can be some information/warning popup built into
an application, which shows up only if some combination of events happens. There can
be some non-compliant data in the database, which may cause application rules to be
broken. Similar problems can be caused by test data failures. For all such issues, the
Framework provides a unique place for exception handling. Since there are no
repetitions, one has to handle such exceptions at one place only. Because the same
code is used everywhere, this exception handling is reflected in all the scripts. For
example, let’s say that there is a ‘Wrong password’ popup shown during login, in case
the password is incorrect. Normally, It will be difficult to handle this popup in every script
as all the scripts essentially do login. Whereas in the Framework we have one login
function in the Navigation that’s used by all the scripts. Taking care of this popup in login
function makes all the scripts safe for this popup.

9 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

4. Well Organized Code
The code gets organized and becomes easy to debug and maintain as we are using a
structured approach of tiers and libraries. The functions get organized in a disciplined
manner and locating them becomes very simple and straightforward due to well-defined
tiers. This discipline is quite vital for the Framework.

5. Generic Concept
Concept of the Framework is quite generic and is not tied to any particular tool,
technology, platform, architecture or application. It can easily be applied to diverse
environments and various tools. This helps in transitions and also eliminates need to be
a tool-expert to follow the concepts.

6. Test Data Management

The Framework underlines the fact that test data is quite vital part of test automation.
Special attention is given to ensure that the data is kept separate from the code. The
special library that we made for handling test data related operations stresses this idea.
Due to clear isolation and efficient data failure checks embedded in functions, most of
the possible automation failures are eliminated.

Value Propositions

1. Reusability
As illustrated in
detail in previous
chapters the
Framework works
on a principle of
reusability.
As we keep on
developing new
scripts the
Framework keeps
growing stronger
and the newer script
takes lesser time
than previous. The
matrix diagram
illustrates this
concept clearly as how the need for making newer functions goes down on different tiers
as the number of developed scripts increases. This saves cost in long term, as against
the traditional automation project wherein one has to keep investing almost the same
amount of time in scripting for every new script developed.

2. Maintainability
This is one of the biggest factors that come into consideration when the business makes
a decision regarding whether or not they should invest money in developing scripts.
Automation has developed a bad reputation among many non-QA people because of the
high mortality and less flexibility of the scripts. Come new build and half the scripts stop
working, is not good news for anybody spending big money for automation scripting.
There are several reasons for this, like heavy repetitions, unprecedented dependency on
application data, unavailability of scripters who can fix the broken scripts etc. A small

10 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

change in the application normally causes requirement of big changes in tens of scripts.
The way the Framework manages changes revolutionizes this process of maintenance.
Because the repetitions are completely avoided, one change in application necessarily
requires just one change in the automation engine. Because of the well-organized and
easily interpretable scripts, the dependency on scripters is also minimized to a great
extent. It’s proven fact that the Framework allows quick maintenance in long term
projects where a traditional automation requires 100% rescripting. When it comes to
selling the concept of the Framework maintainability has to be termed as the USP.

3. Smart Resource Utilization

Implementation of the Framework has one surprising benefit, which is not evident at first.
In traditional automation projects, Normally what happens is that the number of scripts is
distributed among the number of automation resources based on their availability and
their expertise with the tool. Again there are factors such as application knowledge and
experience of development, which account for efficiency of the scripters. Thus one is
forced to do an unequal distribution of scripts among the resources. This not only causes
variation in quality but also makes the scripts non-uniform. If one goes in for the
Framework, the resource allocation gets a new dimension. One can identify core team of
automation engineers, which includes people with expertise in scripting tool and having
a good grip on application knowledge. This core team will make the initial scripts and
build up the platform of basic functions and libraries. Initially, since there is a lot of work
to be done on tiers 2, 3 and 4, these people are required to spend full time on this work.
Once the core team feels that the Framework is becoming stable, we introduce a big
team of scripters. These people can have limitations such as less availability, limited
application knowledge, less competency with the automation tool. These people can
then work purely on Tier 1 and make scripts, while the core team will support the mass
scripting effort by creating whatever additional functions are required on Tier 2, 3 and 4.
Such a contrasting team works very well in symphony helping the rapid scripting effort in
the best way.

4. Ease of transition – Developer Independent Code

In a highly volatile scenario, it is never less than risky to depend on an individual. The
scripts made using traditional method have this well-known problem of developer-
dependency. Especially in case of the complicated scripts wherein there is some
complex code written to accomplish some really difficult-to-automate task, it is very
difficult for a new person to understand what’s going on? Instead if we follow the
Framework methodology, the code becomes better organized and developed in
prescribed steps. It can therefore be comprehended easily by a third person.

5. Creation of robust code repository

The concept of reusability explained above can be taken to a new dimension if we can
use some functions across multiple applications. Since the lower two tiers
(GUIObjectUtility and GUIMapUtility) are essentially application independent, they can
be shared across multiple applications. For example the GUIObjectUtility developed for
one web-based application should be usable for any other web-based application, as the
objects in the web page and their behavior remain the same. This gives a great
advantage for organizations working on multiple projects at the same time.

11 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

5. Discipline in The Framework – Risks and Regulations
Risks associated with use of the Framework

Now that we have seen various benefits of using the Framework, it will be wise to
see the other side of the coin as well. Let us try to understand what are the potential
risks involved in use of the Framework and what can be done to mitigate those.

1. Susceptibility of the functions to bugs

The libraries are quite vital in the Framework. The functions are the basic building blocks
and hence a potential for a big collapse. In scripts made using traditional method, if one
script breaks because of some bug/application change, the problem remains isolated to
that particular script. But just assume that some function in one of the libraries has some
problem. Now because many of the scripts are using this function, all of them can be
potentially affected causing magnification of the problem. This is a typical QA issue, and
requires that all the libraries go through proper QA testing. It adds responsibility on the
core team creating the library functions, that they follow proper SDLC (Software
Development Life Cycle).

2. Resource Contention
Second major problem arises from improper resource management and poor automation
planning. Because the scripts share same libraries, there is a possibility that more than
one person is working on the same piece of code at the same time. This is a typical
configuration management issue. Because we have the libraries playing such a vital role
in the automation engine, it is recommended that one uses some configuration
management tool and avoid using ad hoc methods like shared network drives. There
should be timely backups and all the updates should strictly follow check-out-update-
check-in procedure.

The Framework Rules and Regulations

Let us spend some attention on different ways we can use to reduce the risks and
make the best use of the Framework.

1. The Framework rules

It is the responsibility of the Framework designer that they strictly enforce the Framework
rules. These rules govern inter-tier calls, test data management, etc. It is recommended
that one should only be allowed to call a function in a tier, one level below itself i.e. one
can call a Navigation (Tier 2) function from script (Tier 1) and GUIObjectUtility (Tier 3)
function from Navigation (Tier 2). All other inter-tier calls - like skipping a tier in-between
like calling GUIObjectUtility (Tier 3) from the script (Tier 1), lateral calls - like calling a
function on the same tier, etc must not be allowed. It is also recommended that one
should follow certain rules while accessing test data. Because the lower tiers are shared
across different scripts, there should not be direct access to the test data files from the
Navigation and lower tiers. All test data must be handled in the main script (Tier 1) only.
This also prohibits hard coding of data file names in lower tier functions.

2. Scripting standards
Every development exercise necessarily has some coding standards. Since we are
making an effort to take scripting into a new era where it is no way inferior to

12 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

development, it is recommended that for every project there should be a documented set
of standards. Following points might help building up these standards.
• There should be standardized naming conventions for functions, variables, and data
tables, scripts and Test Cases, which should be strictly enforced.
• There is normally a set of standards available for all the automation tools; some of
the things can be inherited from that.
• Normally it is a good practice if every instance of user input is parameterized and
comes from a data table. This allows flexibility of test data and allows us to use the
script for variety of input combinations.
• Exception handling guidelines are important section in the standards. There can be
several things that can possibly affect smooth execution of the script. May it be test
data failure or some application popup. These guidelines will direct the scripters
mentioning what action should be taken in such an event.
• The error logging should be standardized as well. The execution log is the prime
outcome of an automation test execution and a formalized log always makes it easy
to analyze the test results later.
• There are other miscellaneous things like commenting, indentation etc. A clear
documentation of expectations helps scripters create uniform scripts.

3. The Framework Documentation

Because we have the code organized in several functions in several libraries, it becomes
mandatory to document these functions. This document should list the functions
categorized by libraries. Every function description should mention a brief purpose of the
function along with the input and the output parameters to the function. Additionally
every library can have a small write-up describing the basic purpose of that library and
other details like author and code-change log. It was noticed that this document is quite
identical to function-header level comments in the code itself, so going a step ahead, it is
possible to auto-generate this document by parsing the script files. This not only saves
the efforts but also makes the documentation uniform.

4. Proper Test Cases

Test Cases form the base of a good automation engine. The Test Cases for automation
are slightly different than the ones for manual testing. This is because of the fact that we
need to explicitly mention a few things like “wait for new page to be displayed” which can
be implicitly assumed in manual testing. The Framework gives an additional accessory
by helping in auto-generating the Test Cases. Since the Tier 1 in the Framework maps
directly to steps in the Test Case, if one parses the comments from the script he ends up
deriving the Test Case from the script itself.

5. Training new members of the team.

It is quite important that the human resources that implement the concept of the
Framework get a proper training. This training should not only cover the automation tool,
but also adequate application knowledge and basic understanding about the Framework
methodology. This becomes even more important for new members joining an existing
team that has already put lots of things in place.

13 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte

6. The Framework in Action – Real-life Implementations
Application: Web – Tool: Rational Robot

The most important benefit of implementing the Framework for a web-based application
is what we call as the ‘early saturation of GUIObjectUtility’, because the web pages have
limited type of objects and any object rarely has more than one possible operation. In
Rational Robot, though there is a way of getting the HTML source, it doesn’t provide
direct access to many important properties and text of HTML objects. So I introduced a
fourth tier called ‘irRational’ which actually did the job of pulling the HTML source from
the page, loading it into an XML, and then accessing individual properties of each object
using XML DOM. Many of the otherwise impossible tasks were easily accomplished by
the use of this ‘irRational’ tier. I also implemented a Java parser that was used to
generate Test Cases from the comments in the script (Tier 1).

Application: Java Client-Server – Tool: Rational Robot

For a non-web application working with GUI Objects is not that simple. This is where a
thoroughly developed GUIObjectUtility comes handy. It avoids reinvention of wheel by
unifying all the object operations on the third tier and allows us to concentrate on
application logic and business processes on higher tiers. Even if Java plug-in is
available, some objects might give some problems. Tier irRational is a good place to
write user-created functions for such objects. A good example is a Java Tree. I used
XML to organize the tree data and access different branches. I also did comprehensive
configuration management using a web-based tool PVCS.

Application: Terminal Emulator – Tools: Rational Robot and WinRunner

In terminal emulator everything works based on co-ordinates and fields. When

implementing the Framework, the GUIObjectUtility shrinks to a very few functions for
sending keys and verifying text on screen. WinRunner has a Terminal Emulator add-in
but Rational Robot doesn’t. Here I used APIs given by Attachmate on the fourth tier
(irRational). This was the first time I felt need for extensive documentation. I
implemented a VB-XML based documentation generator. It uses the header level and
function level comments to generate API documentation in XML format. This is then
displayed in HTML format using DOM parser written using JavaScript.

7. Going Ahead – Conclusions

The Framework’s simplicity and ease of use attracts the automation leads. The
speed of script development impresses managers. The great comfort of maintainability
makes it popular among the scripters. But one should not forget that the whole concept
is still young and immature. We want to make automation a separate software
development discipline. It should enjoy the luxuries of adequate pre-allocated time in
project plan, specialized resources, and QA. The Function APIs should become a big
code-base, which is reusable across projects. One should not be required to work at all
on the Tier 3 and 4 anymore. The age of short-lived, ad hoc, record-and-replay scripts is
coming to an end, and we see a new era starting. Era wherein people spend time
designing the architecture of the scripts, developing test data models. Everything is
planned and follows an optimized process. The Framework is just a beginning!

14 4-Tier Architecture Of The Functional Test Automation Framework Pankaj Bhatte