Framework Automation++

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 scriptmortality 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 searchresult 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.

III.

IV.

V.

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. 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. 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. 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 createuse-anddestroy 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 developerdependency. 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-updatecheck-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