A test automation framework is a set of assumptions, concepts, and practices that provide support for automated software testing. Framework must be easy to expand, maintain, application independent and perpetuate. This will allow us to implement that extra effort just once, and execute it for every call to any component function.
Framework should handle all the details of ensuring we have the correct window, verifying the element of interest is in the proper state, doing something with that element, and logging the success or failure of the entire activity.
Linear Framework
This is the basic framework everybody can follow where we cannot see any reusability. Each individual prepares separate script and it can be used only where it exists. It cannot reduce re-work
The test script modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test (AUT). These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case. This one is the simplest to grasp and master. It's a well-known programming strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites.
Data Driven Framework
Data Driven scripts are those application data specific scripts captured or manually coded in the automation tool’s proprietary language and then modified to accommodate variable data. Variables will be used for key application input fields and program selections allowing the script to drive the application with external data supplied by the calling routine from the data table during test run.
These data driven scripts often still contain the hard coded and sometimes very fragile recognition strings for the window components they navigate. A test automation framework relying on data driven scripts is definitely the easiest and quickest to implement when we have the technical staff to maintain it. We need to update test data each time business changes and need to update test script when we have changes in the application user interface.
Keyword Driven Framework
Sometimes this is also called "table driven" test automation. It is typically an application-independent automation framework designed to process our tests. These tests are developed as data tables using a keyword vocabulary that is independent of the test automation tool used to execute them. This keyword vocabulary should also be suitable for manual testing
The data table records contain the keywords that describe the actions we want to perform. They also provide any additional data needed as input to the application, and where appropriate, the benchmark information we use to verify the state of our components and the application in general.
Another advantage of the keyword driven approach is that testers can develop tests without a functioning application as long as preliminary requirements or designs can be determined. All the tester needs is a fairly reliable definition of what the interface and functional flow is expected to be like. From this they can write most, if not all, of the data table test records.
Fortunately, this heavy, initial investment is mostly a one-shot deal. Once in place, keyword driven automation is arguably the easiest of the data driven frameworks to maintain and perpetuate providing the greatest potential for long-term success.
Hybrid Framework
The most commonly implemented framework is a combination of all of the above techniques, pulling from their strengths and trying to mitigate their weaknesses. This hybrid test automation framework is what most frameworks evolve into over time and multiple projects
