preload

GUI Automation Components

Posted by Albert Gareev on Sep 09, 2014 | Categories: DocumentsImplementationRequirements

To perform testing, GUI automation scripts need to encapsulate the following components:

  • Test data, used for input and verification.
  • Service functionalities, like reporting, data retrieval, etc.
  • GUI mapping – set of logical names of GUI controls mapped to their physical properties.
  • GUI operation, i.e. recognition of controls, sending commands, retrieving property values.
  • Test instructions (test logic) – the actual testing part.

These components have distinct characteristics and requirements.

Component

Characteristics

Requirements

Test Data The most changing part:

  • Might be different between two environments
  • Can be created and modified on the go
  • Can be part of different test cases
  • Can come in very high volumes
To account for the characteristics:

  • Must be stored separately from other test components
  • Must be stored in different versions
  • Must be structured and optimized
  • Testing scripts must be easily switchable from one to another dataset
  • Must be stored in Version Control System

 

Service Components The most stable part:

  • Limited set of functions
  • Do not depend on GUI technology
  • Do not depend on test logic
  • Must be consistently used by all scripts
To account for the characteristics:

  • Must be developed and maintained in isolated functions
  • Must be harnessed by Unit Tests
  • Testing scripts must not have custom implementation of any service functions
  • Must be stored in Version Control System
GUI mapping The most fragile part:

  • Absolutely depends on GUI technology
  • May change from build to build without developers’ intention
  • Has linear creation and maintenance effort – each object has to be individually mapped
  • GUI controls may not have well-distinguishable physical properties
  • Different GUI controls may have the same business meaning, especially on different screens
  • Different GUI controls may have the same physical properties
  • Has a degree of repetition, because different testing scripts may use the same GUI object
To account for the characteristics:

  • Mapping must be well-thought, properly structured and designed – must not rely on automatic capture of objects’ properties
  • Must be reusable to the max possible extent
  • Must be supported from Development side, by addressing Testability issues
GUI Operation Very stable part – changes only with major changes in UI technology:

  • Limited set of functions
  • Do not depend on test logic
  • Must be consistently used by all scripts
To account for the characteristics:

  • Must be developed and maintained in isolated object classes
  • Must be stored in different libraries
  • Testing scripts must not have custom implementation of any GUI Operations
  • Must be stored in Version Control System
Test Logic Fairly stable part – if implemented at the proper abstraction level, would need changes only in case of changes in the business / test workflow:

  • Very limited set of instructions: Input, Verify constitute over 80% of all.
  • Do not depend on GUI technology
  • Must be consistently used by all scripts

 

To account for the characteristics:

  • Must be stored separately from other test components
  • Must have unified call and exit interface to be used by a standard test driver in scenario testing
  • Must be stored in Version Control System

 

 

 


  • Leave a Reply

    * Required
    ** Your Email is never shared

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.