One Point Maintenance

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.

An Example of One Point Maintenance

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:

• Patient
  • Login
  • Make an appointment
  • Logs out
• Physician
  • Logs In
  • Enters a diagnosis
  • Prescribes medication
  • Follow up appointment
• System
  • Records the appointment date and sends an email to the patent
  • Records the next appointment date and sends a confirmation email
  • Based on the patient’s medical coverage
    • Enter the cost of the appointment
    • The cost of the medications
    • Updates the patents out of pocket deductibles accumulator
    • Send out a receipt

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:

• Build a separate function and error handler for each screen
  • One function – one screen (or window)
  • One error handler for each screen
  • This function only deal with the objects and navigation properties of the one screen, regardless of the nature of that screen.
  • The error handler is devoted to unexpected conditions that may arise on that one screen
  • The login screen has two or three objects while the Patient Appointment screen may have thirty of forty objects, according to the Principle, there is still one function per screen regardless of its complexity
  • As each screen is used by literally thousands of test cases, building a separate function for each screen is how to apply the principle of One Point
  • When changes are made to screens, the automation engineer, makes updates to the individual functions for that screen
  • The Maintenance is .One Point. due to applying this architectural principle. Instead of making hundreds of changes across the system which can get confusing and error prone, all that is required is to locate the individual screen function and make the updates in one time at One Point

Summary: Principle One – One Point Maintenance (OPM)

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.

• Error handlers
  • Differentiate between hard and soft error or messages
  • Used for negative testing
  • Verifying the error or warning message is correct and is display at the appropriate time and place
  • Designed to handle modal windows
  • One error handler for each navigation screen

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.