Automation Framework Architecture Types: Oracle

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.

shrivastava-automation-fig02
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.
shrivastava-automation-fig03
Figure 3: Optimum Framework Characteristics