Library Framework

Test Library Architecture

The test library architecture framework is very similar to the test script modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scripts. This framework requires the creation of library files which has reusable code represented in modules, sections and functions of the application-under-test. These library files are then called directly from the test case script.

           

Advantages:

§     Performance of automation scripts increases due to higher code re-usability

§    Functionality changes can be accommodated easily by updating only the specific "Business Function" script

§   Object recognition changes can be easily accommodated in tools without inbuilt object repository

Disadvantages:

§    Technical expertise is necessary to write Scripts using Test Library Framework

§    More time is needed to plan and prepare test scripts

§    Cannot drive the data from database

Modular Framework

Test Script Modularity

The test script modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.

Of all the frameworks, this 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.

Advantages:

§    Fastest way to generate script

§    Modular division of scripts leads to easier maintenance

Disadvantages:

§   Cannot make use of reusable libraries

§   Cannot drive the data from database

Keyword Driven Framework

Keyword-Driven or Table-Driven Testing

Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords which are independent of the test automation tool used to execute them, and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.

There are 2 basis components in Keyword Driven Framework viz. Keyword, Application Map.

What is a Keyword or Action?

Keyword is an Action that can be performed on a GUI Component. Ex. For GUI Component Textbox, some Keywords (Action) would be InputText, VerifyValue, and VerifyProperty and so on. 

What is Application Map or Control?

An Application Map provides Named References for GUI Components. Application Maps are nothing but ‘Object Repository’. 

Example:  The following table represents Keyword driven framework for ‘Calculator’ application. The "Window" column contains the name of the application window where we're performing the mouse action (in this case, they all happen to be in the Calculator window). The "Control" column names the type of control the mouse is clicking. The "Action" column lists the actions taken with the mouse (or by the tester). And the "Arguments" column names a specific control (1, 2, 3, 5, +, -, and so on).

Window	Control	Action	Arguments
Calculator	Menu		View, Standard
Calculator	Pushbutton	Click	1
Calculator	Pushbutton	Click	+
Calculator	Pushbutton	Click	3
Calculator	Pushbutton	Click	=
Calculator		Verify Result	4
Calculator		Clear
Calculator	Pushbutton	Click	6
Calculator	Pushbutton	Click	-
Calculator	Pushbutton	Click	3
Calculator	Pushbutton	Click	=
Calculator	*	Verify Result	3

Advantages:

§    Detail Test Plan can be written in Spreadsheet format containing all input and  verification data.

§    Prior to the Detail Test Plan being written, if "utility" scripts are created by people who are well versed with the automated tool’s and Scripting language, then the tester can use the Automated Test Tool immediately via the "spreadsheet-input" method, without needing to learn the Scripting language.

§    The tester needs to learn only the "Key Words" required, and the specific format to use within the Test Plan. This allows the tester to be productive with the test tool very quickly, and allows more extensive training in the test tool to be scheduled at a more convenient time.

Disadvantages:

§    Development of "customized" (Application-Specific) Functions and Utilities requires proficiency in the tool’s Scripting language.

§    If application requires more than a few "customized" Utilities, the tester has to learn a number of "Key Words" and special formats. This can be time-consuming, and may have an initial impact on Test Plan Development. Once the testers get used to this, however, the time required to produce a test case will be greatly improved.