Broad Types of Automation Framework
Automation frameworks can be classified according to four broad types, each of which has unique advantages and disadvantages, as shown in Table 1. The choice of a particular type depends upon a wide range of external factors.
| Factor | Linear/Structured Test | Data Driven | Keyword Driven | Hybrid |
| Objective | This consists of procedural code or a set of instructions | Data is persisted outside the test | Code is bound with keywords that are then used to implement the desired tests | This is a combination that chooses the strengths of other framework types and mitigates their weaknesses |
| Approach | The approach is logical with a view of making the task at hand work | Data is the key and everything is designed to accomplish the desired task with a simple change of data | Most of the common tasks are organized into basic keywords that are bound with associated code; complex tasks are achieved by combining multiple keywords | The approach could depend on what needs to be accomplished and also on the imagination of the architect |
| People skill requirement | Does not require advanced programming knowledge; simple logical skills are sufficient | Might require intermediate-level programming skills coupled with logical skills | Might require intermediate-level programming skills coupled with logical skills | Might require advanced programming knowledge, which might be used to make the framework more generic and adaptable |
| Complexity | Low | Medium | Medium | High |
| Framework development time comparison | Might require less time to develop the framework for individual cases | Requires a moderate amount of time | Requires a moderate amount of time | Might require significantly more time |
| Individual-test development time | Higher | Lower once the base script is developed | Lower once the base script is developed | Lower once the base script is developed |
| Individual-test development time | Higher | Lower once the base script is developed | Lower once the base script is developed | Lower once the base script is developed |
| Flexibility with respect to changes in the system under test and technology | Low | Medium | Medium | High |
| Advantages | Simplicity and low cost | Moderate complexity and flexibility | Moderate complexity and flexibility | High flexibility with boundless possibilities |
| Disadvantages | Low flexibility | Flexibility only in terms of data | Flexibility only in terms of components | Might become very complex over time and might require specialized support |
| Ideal usage scenario | Automation of simple repetitive tasks, which are expected to remain relatively unchanged over time | Automation of repetitive tasks for which only the data is expected to change over time with little or no effect on the technology or the system under test | Automation of repetitive tasks for which significant change is expected in terms of the system under test, but data remains relatively constant | Automation of repetitive tasks for which significant change is expected over time in terms of technology, the system under test, or data; most suitable for ERP applications |
| Example development tools | Any record-and-play tool, for example, Selenium, Quick Test Professional (QTP), or Oracle Applications Testing Suite (OATS) | Any recording tool that has proficiency in scripting languages such as VBScript or JavaScript and provides external data store integration | Any recording tool that has proficiency in scripting languages such as VBScript or JavaScript | Might require custom component development and programming language support |
Figure 2 shows a framework comparison matrix that is based on data from a random sample.
Figure 2: Framework Comparison
Design Strategy for Enterprise Products
Enterprise products are large, complex, and ever-evolving software products that, of late, have resolved to an iterative incremental-growth model. To keep up with the growth rate of an enterprise product, the corresponding testing framework should broadly conform to a design that has the following characteristics:
- Complete: The framework and its assets should allow complete end-to-end testing of the product suite, starting from initial setup and preparation of the environment to various specialized subprocesses and critical one-time tasks.
- Open: As much as possible, the framework should be based on open technologies, such as Java, to limit the development and maintenance costs. Openness might also allow cross-tool execution when a suitable API exits or can be developed.
- Integrated: The framework should allow easy integration with a maximum number of tools and components in the periphery of the product suite.
Figure 3: Optimum Framework Characteristics
- Log in to post comments
Tags