OneStopTesting - Quality Testing Jobs, eBooks, Articles, FAQs, Training Institutes, Testing Software, Testing downloads, testing news, testing tools, learn testing, manual testing, automated testing, load runner, winrunner, test director, silk test, STLC

Forum| Contact Us| Testimonials| Sitemap| Employee Referrals| News| Articles| Feedback| Enquiry
 
Testing Resources
 
  • Testing Articles
  • Testing Books
  • Testing Certification
  • Testing FAQs
  • Testing Downloads
  • Testing Interview Questions
  • Career In Software Testing
  • Testing Jobs
  • Testing Job Consultants
  • Testing News
  • Testing Training Institutes
  •  
    Fundamentals
     
  • Introduction
  • Designing Test Cases
  • Developing Test Cases
  • Writing Test Cases
  • Test Case Templates
  • Purpose
  • What Is a Good Test Case?
  • Test Specifications
  • UML
  • Scenario Testing
  • Test Script
  • Test Summary Report
  • Test Data
  • Defect Tracking
  •  
    Software testing
     
  • Testing Forum
  • Introduction
  • Testing Start Process
  • Testing Stop Process
  • Testing Strategy
  • Risk Analysis
  • Software Listings
  • Test Metrics
  • Release Life Cycle
  • Interoperability Testing
  • Extreme Programming
  • Cyclomatic Complexity
  • Equivalence Partitioning
  • Error Guessing
  • Boundary Value Analysis
  • Traceability Matrix
  •  
    SDLC Models
     
  • Introduction
  • Waterfall Model
  • Iterative Model
  • V-Model
  • Spiral Model
  • Big Bang Model
  • RAD Model
  • Prototyping Model
  •  
    Software Testing Types
     
  • Static Testing
  • Dynamic Testing
  • Blackbox Testing
  • Whitebox Testing
  • Unit Testing
  • Requirements Testing
  • Regression Testing
  • Error Handling Testing
  • Manual support Testing
  • Intersystem Testing
  • Control Testing
  • Parallel Testing
  • Volume Testing
  • Stress Testing
  • Performance Testing
  • Agile Testing
  • Localization Testing
  • Globalization Testing
  • Internationalization Testing
  •  
    Test Plan
     
  • Introduction
  • Test Plan Development
  • Test Plan Template
  • Regional Differences
  • Criticism
  • Hardware Development
  • IEEE 829-1998
  • Testing Without a TestPlan
  •  
    Code Coverage
     
  • Introduction
  • Measures
  • Working
  • Statement Coverage
  • Branch Coverage
  • Path Coverage
  • Coverage criteria
  • Code coverage in practice
  • Tools
  • Features
  •  
    Quality Management
     
  • Introduction
  • Components
  • Capability Maturity Model
  • CMMI
  • Six Sigma
  •  
    Project Management
     
  • Introduction
  • PM Activities
  • Project Control Variables
  • PM Methodology
  • PM Phases
  • PM Templates
  • Agile PM
  •  
    Automated Testing Tools
     
  • Quick Test Professional
  • WinRunner
  • LoadRunner
  • Test Director
  • Silk Test
  • Test Partner
  • Rational Robot
  •  
    Performance Testing Tools
     
  • Apache JMeter
  • Rational Performance Tester
  • LoadRunner
  • NeoLoad
  • WAPT
  • WebLOAD
  • Loadster
  • OpenSTA
  • LoadUI
  • Appvance
  • Loadstorm
  • LoadImpact
  • QEngine
  • Httperf
  • CloudTest
  •  
    Languages
     
  • Perl Testing
  • Python Testing
  • JUnit Testing
  • Unix Shell Scripting
  •  
    Automation Framework
     
  • Introduction
  • Keyword-driven Testing
  • Data-driven Testing
  •  
    Configuration Management
     
  • History
  • What is CM?
  • Meaning of CM
  • Graphically Representation
  • Traditional CM
  • CM Activities
  • Tools
  •  
    Articles
     
  • What Is Software Testing?
  • Effective Defect Reports
  • Software Security
  • Tracking Defects
  • Bug Report
  • Web Testing
  • Exploratory Testing
  • Good Test Case
  • Write a Test
  • Code Coverage
  • WinRunner vs. QuickTest
  • Web Testing Tools
  • Automated Testing
  • Testing Estimation Process
  • Quality Assurance
  • The Interview Guide
  • Upgrade Path Testing
  • Priority and Severity of Bug
  • Three Questions About Bug
  •    
     
    Home » Testing Articles » Automated Testing Articles » Test Automation Architecture One Point Maintenance

    Test Automation Architecture One Point Maintenance

    A D V E R T I S E M E N T


    Abstract

    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:

    1. One Point Maintenance
    2. Data Driven
    3. Test Case Independence

    This article will address the first principle: One Point Maintenance.

    Introduction

    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.

    Frameworks versus Architecture

    Frameworks

    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.

    Architecture

    As stated in the abstract; The three organizing principles of an independent automation architecture are as follows:

    • One Point Maintenance
    • Data Driven
    • Test Case Independence

    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: One Point Maintenance - Principle One (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.



    More Automated Testing Articles
    1 2 3 4 5 6 7 8 9 10 11 Next



    discussionDiscussion Center
    Discuss
    Discuss

    Query

    Feedback
    Yahoo Groups
    Y! Group
    Sirfdosti Groups
    Sirfdosti
    Contact Us
    Contact

    Looking for Software Testing eBooks and Interview Questions? Join now and get it FREE!
     
    A D V E R T I S E M E N T
       
       

    Members Login


    Email ID:
    Password:


    Forgot Password
    New User
       
       
    Testing Interview Questions
  • General Testing
  • Automation Testing
  • Manual Testing
  • Software Development Life Cycle
  • Software Testing Life Cycle
  • Testing Models
  • Automated Testing Tools
  • Silk Test
  • Win Runner
  •    
       
    Testing Highlights

  • Software Testing Ebooks
  • Testing Jobs
  • Testing Frequently Asked Questions
  • Testing News
  • Testing Interview Questions
  • Testing Jobs
  • Testing Companies
  • Testing Job Consultants
  • ISTQB Certification Questions
  •    
       
    Interview Questions

  • WinRunner
  • LoadRunner
  • SilkTest
  • TestDirector
  • General Testing Questions
  •    
       
    Resources

  • Testing Forum
  • Downloads
  • E-Books
  • Testing Jobs
  • Testing Interview Questions
  • Testing Tools Questions
  • Testing Jobs
  • A-Z Knowledge
  •    
    Planning
    for
    Study ABROAD ?


    Study Abroad


    Vyom Network : Free SMS, GRE, GMAT, MBA | Online Exams | Freshers Jobs | Software Downloads | Programming & Source Codes | Free eBooks | Job Interview Questions | Free Tutorials | Jokes, Songs, Fun | Free Classifieds | Free Recipes | Bangalore Info | GATE Preparation | MBA Preparation | Free SAP Training
    Privacy Policy | Terms and Conditions
    Sitemap | Sitemap (XML)
    Job Interview Questions | Placement Papers | SMS Jokes | C++ Interview Questions | C Interview Questions | Web Hosting
    German | French | Portugese | Italian