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
|