preload

Basic Test Flow: GUI Screen Verification

Posted by Albert Gareev on May 22, 2008 | Categories: Patterns

Parent page: Basic Test Flows

GUI Screen Verification Test Flow

Entry/Exit Points

Entry Point. Single. GUI screen (window, web page, etc.).

Exit Point. Single. Same GUI screen.

Operations

GUI interaction – None

GUI observation 

  • checking screen (windows, web pages, etc.) in context of which GUI objects are checked
  • checking GUI objects (exist, enabled, etc.)
  • check GUI objects’ data (text displayed, item selected, etc.)

 

Evaluation – assessment of Pass/Fail criteria for GUI observations.

Pass/Fail Criteria

Fail Criteria

  • GUI observation failure
  • Assessment criteria failure

 

Stop Criteria

  • GUI context not available
  • End of steps reached

 

Pass Criteria

  • No failures
  • End of steps reached

 

Test Data

Input Data. None.

Verification Data. The Test Flow uses verification data to check GUI objects’ actual data. Verification Data could be hard-coded or combination of hard-coded and parameterized data.

Example

1. GUI observation. “Target screen exists”.

2. GUI observation. “Country combo box exists”.

3. GUI observation. “USA selected list item matches expected data”.

4. GUI observation. “State combo box exists”.

5. GUI observation (evaluation failed). “Indiana selected list item does not match expected data”.

6. GUI observation. “City combo box exists”.

7. GUI observation. “Chicago selected list item matches expected data”.

Commentary

GUI Screen Verification test flow is static: no interactions with  application under test required. It consists of a sequence of simple observations and assertions.

Note the scope of the Flow is limited to verification of those GUI objects and those their properties that are explicitly defined. For instance, “Accept”, “Modify”, or “Cancel” buttons presented on the GUI screen, will not be noticed or verified by a script executing the test flow.

Implementation

Most of automation tools offer a “native” static verification mechanism, called a Checkpoint. Checkpoint may use hard-coded or parameterized Test Data.

Coverage

The Coverage is in direct dependency on the number of GUI objects and their properties enlisted for verification. However, the bigger the number of objects enlisted in a checkpoint, the higher its maintenance cost. Maintenance cost grows exponentially.


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.