Most Second Generation frameworks are a hybrid of both Data-driven and Functional Decomposition, but it is possible to have one without the other, so they will be discussed independently.
Functional Decomposition PDF Print E-mail
Functional Decomposition refers broadly to the process of producing modular components (user-defined functions) in such a way that automated test scripts can be constructed to achieve a testing objective largely by combining these existing components.
The modular components are often created to correspond with application functionality, but there are a lot of different types of user-defined functions that may be created. These function types may include the following:
* Utility functions – These are functions that represent fundamental framework actions or the basic functionality of a specific application under test. For example, a function that is responsible for logging into the application would be considered a utility function. These functions can be identified from the requirements or from the manual test cases, related to the groups of tests that are slated for automation.
* Navigation functions – Most applications have several main areas that are navigated to many times during testing. The paths are basic paths that can often very easily be identified at the very beginning of the automation process.
* Error handling functions – Error handling functions are functions created to deal with certain unexpected events that may occur during testing.
* Miscellaneous functions – These are functions that don’t fall under any of the other categories.
The Functional Decomposition framework may vary from having a relatively low level of complexity to high level of complexity, based on the level at which functions are created. Functions may be created for simple tasks such as menu clicks, or may be created for complex functional activities, complex error handling routines, and complex reporting mechanisms.
Functional Decomposition Script Pros
* Increased Reusability – Reusability is greatly increased with the introduction of functional decomposition, because reusable functions may be created and made available for use by multiple tests. Redundancy may be decreased for all tests within a given application, and may also be reduced across multiple applications, depending on the level of abstraction at which the function is created. With increased reusability maintainability is greatly increased.
* Script Independence – Although the Functional Decomposition Framework may use multiple external components, the tests themselves are not being reused. This allows for the introduction of reusability while still maintaining script independence.
* Earlier script development – Functional decomposition makes it possible to in some instances begin developing automated tests even before the application is delivered. Using information gathered from Requirements or other documentation, placeholder components can be created and used for developing automated tests in a top-down development approach. Once the application becomes available the components can be appropriately updated.
* The script is easier to read – Automated tests are easier to maintain when broken into small components because it is simpler to visually determine what the script is trying to accomplish.
* Increased standardization – With the increase of reusable framework components comes increased standardization. Standardization aids in script development, because it decreases much of the guess work involved in creating scripts. In addition, standardization helps with script maintenance, because it decreases guess work involved in figuring out what a script does and how best to fix it.
* Error handling is easier to introduce – Patch work error handling solutions on a script by script basis are difficult to introduce and maintain. With reusable components, error handling that reaches multiple scripts can be introduced. This will ultimately improve the effectiveness of unattended execution of the test scripts.
Functional Decomposition Script Challenges (Cons)
* Required technical expertise – As an automated test framework begins to utilize more technical solutions, that framework, by default, begs for more technically adept resources to design, develop and maintain it. This concept holds true for the functional decomposition framework.
* Intuition is less useful – In order to effectively implement an advanced framework, reliance on intuition must be reduced, while reliance on standards must be increased. While standardization is a positive by product of Functional Decomposition, it also poses a challenge in ensuring resources are aware of standards, understand them, and are able to effectively implement them. Increased documentation will probably be required to identify framework features, particularly documentation that chronicles the functions that exist as part of the framework.
* Maintenance becomes more complex – As the complexity of the framework increases, so does the amount of maintenance that is required. With Linear scripts, maintenance is confined solely to a script that breaks. While, this may result in excess maintenance for Linear scripts (because a single application change can make multiple scripts susceptible to failures), it also helps make maintenance a little less complex. With Functional Decomposition, maintenance is often required for both the framework and specific scripts. While this may reduce the amount of maintenance required, it also makes maintenance a little more complex.
Data-driven PDF Print E-mail
Frameworks built on Data-driven scripting are similar to Linear scripts, in that most of the components that are executed by a Data-driven script largely exist within the body of that script. The difference is seen in how the data is handled. The data used in Data-driven scripts is typically stored in a file that is external to the script. By parameterizing application input fields and associating the external data to its respective parameter, the run-time data will no longer be hard-coded in the script, but rather obtained from the external file. For example, below is a linear script example.
1 Input “John” into Username textbox
2 Input “JPass” into Password textbox
3 Click Login button
4 If “Welcome Screen” exists then
5 Pass the test
6 Else
7 Fail the test
8 End If
A Data-driven version of this script would store the data in an external data file (spreadsheet, database, xml file, etc.), as shown below.
NameParameter
PasswordParameter
John JPass
Sue SPass
Randy RPass
Trina TPass
The data-driven version of the Linear script shown above, may appear as follows:
1 Open Data Table
2 Input
3 Input
4 Click Login button
5 If “Welcome Screen” exists then
6 Pass the test
7 Else
8 Fail the test
9 End If
10 Close Data Table
Notice the data (John, JPass) has been removed from the script, and replaced with data table parameters.
This approach allows for the same blocks of code to be used for different data. Data-driven automation is often considered a technique as opposed to a framework, and when used as a technique, you may have several data-driven constructs within a single test script. Using the Data-driven approach as a framework does little to address many of the challenges that exist in Linear scripts, but reusability is introduced and is useful under certain circumstances.
Data-driven Script Pros
* Reusability – Data-driven scripts offer a relatively simple way to introduce reusability to automated tests. The same block of code can be reused with different data, making it possible for many test cases to be executed with minimal scripting.
* Simple to implement – It’s simple in that it requires minimal updates to existing scripts. It often involves creating parameters in place of hard coded values and placing looping structures around your code.
Data-driven Script Challenges (Cons)
* Redundancy – While Data-driven scripts allow for some degree of reusability, there is still a large degree of redundancy across multiple scripts that perform similar actions. As with Linear scripts, functionality may be duplicated in each respective script, making the scripts susceptible to excessive maintenance.
* One dimensional scripts – Little flexibility is offered in altering the way Data-driven scripts may be executed. Scripts are only readily available to be run at one level, in one location and in one way. If a test manager wants the automator to execute a subset of the total test bed based on defined priorities and risks, or execute the tests in a different environment, or in a different sequence, the automator would have to perform time consuming, run-time analysis of the scripts to make it happen. This will decrease the amount of time available for script execution and analysis.
* Script is difficult to read – With the absence of reusable components, Data-driven scripts are replete with code or automation statements. This will make the script difficult to read and therefore tedious to analyze and maintain. If a statement in the script fails, it is often difficult to determine what application functionality was affected by failure. Likewise, when it becomes necessary to make changes to the script, it is a little more tedious to determine where the changes need to be made.
* Requires higher degree of application knowledge – In order to maintain Data-driven scripts, a higher degree of application knowledge is required. This is directly related to the fact that there is little modularity. Modularity helps to make it clear what a block of application statements is responsible for doing. The loose statements in Linear Scripts make it a little less clear. So when it comes to analyzing and/or debugging a script the automator must first burn a substantial amount of time gaining a mental understanding of what a given block of statements does in order to effectively maintain the script.
No comments:
Post a Comment