The purpose of this paper is to define the Organization of an Automated Testing Architecture that is application independent. Meaning, the architecture is independent of the type of application or the coding language.
The three organizing principles of an independent automation architecture are as follows:
This article will address the first principle: One Point Maintenance.
The world of automated testing has expanded and become more sophisticated over the last twenty years. It has become commonplace to use automation to accelerate testing and is integrated into new methodologies such as Agile, Test Driven Development and others. The value and rationale has been established and the debate is basically over.
There is a great deal of literature on this topic such as 1) Tool selection, 2) Ease of use, 3) How to get started, 4) How to be successful and so on.
From the point of view of the author, what is lacking is how to organize, build and maintain an Architecture that is application independent.
The reason this is so important is that it.s the architecture that is the determining factor for success regardless of any other particular criteria.
One point of discernment is the difference between an architecture and a framework as the terms are often used interchangeably.
Framework typically refers to the various components or qualities of an automation system, such as; 1) Re-usable modules, 2) Common functions such as a .login. or .place an order. function., 3) Results and error logs, 4) Drivers that call sets of cases, 5) Ease of use and so on. There is a relatively long list of framework components.
Frameworks, from this point of view, are mostly organized around the concept of .Common.. That is, what are the common elements, tasks or qualities that can be identified and combined to reduce redundancy and increase efficiency?
Frameworks are an essential part of an automated testing system; however, the position taken here is that it.s the Architectural design which allows for the development of the framework.
We will now focus on the topic of an Automation Architecture, emphasizing the three organizing principles and their .taken for granted. assumptions.
As stated in the abstract; The three organizing principles of an independent automation architecture are as follows:
One Point Maintenance is the primary organizing principle of the architecture. It refers to the ability to make one change, in one place; that will automatically updates a large number of test cases.
This principles ensure that the code will not be redundant and that the automated testing system can quickly accommodate application changes.
It will prevent the system from slowing down the automated testing effort or becoming a “bottleneck" for the QA team, it allows the QA team to meet time project time constraints. This one principle will undermine most objections to automated testing as one point maintenance reduces cost, increases coverage, and saves time and effort to keep the system up and running.
I once worked for a healthcare provider where I was responsible for the automated testing of an enterprise wide electronic medical record system that had more than eight million users nationwide. Note: from the point of view of One Point Maintenance the platform is not relevant.
One end-to-end test we automated navigated around thirty (30) screens; here is a high level summary:
The health provider has hundreds of different policies, deductibles varied depending on the policy type and other variables. There are literally thousands of significant variations of this test scenario, which will be referenced when providing examples of the other two principles; Data Driven and TestCase Independence (see later papers).
Given the complexities of the test case, how does one apply the principle of One Point Maintenance with automated testing? Here are the steps to follow:
The application of this architectural principle, One Point Maintenance, implies the individual building the system understands its intrinsic value and implements throughout the design and implementation of the system.
The actual implementation begins by defining the navigation sequence for each test scenario which includes all the screens or windows and associated error handlers.
The screen or window is the first point of reference, sometimes referred to as .Object Page Reference.. The reason for bringing up this topic now is that OPM requires a point of reference that groups a set of equivalent objects and encapsulates the user experience. That is, the user navigates from screen to screen, to complete a task, such as placing an order. The equivalent objects exist on one screen; consequently, when an object changes, one screen update is all that is required from a maintenance point of view.
OPM implementation takes place at the screen level and enabling the engineer to easily keep up with application changes.
Let’s discuss the importance of error handlers for a moment in regard to the principle of One Point Maintenance.
OPM applies to error handling scripts in the same manner as navigation screens. The engineer creates one error handler for each screen so as new error, or warning, messages display the .single. point to code for their occurrence is clearly defined. Thereby maintaining the OPM architectural principle throughout the automation framework.
Continuous thinking of OPM and consciously designing it into the automation framework will result in an automated testing system that is easy to maintain, fast to update and has the capability to scale as needed.