Basic Test Flow: Data Entry with Confirmation

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

Parent page: Basic Test Flows

On-Screen Data Entry Flow with Confirmation

Entry/Exit Points

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

Exit Point. Single. Confirmation GUI screen.


GUI interaction – typing text, selecting items, clicking buttons, etc.

GUI observation 

  • checking screen (windows, web pages, etc.) in context of which GUI operations are performed
  • checking GUI objects with which operations are performed
  • checking confirmation screen


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

Pass/Fail Criteria

Fail Criteria

  • GUI interaction failure
  • GUI observation failure
  • Assessment criteria failure


Stop Criteria

  • GUI context not available
  • End of steps reached


Pass Criteria

  • No failures
  • End of steps reached
  • Confirmation screen appeared with expected details


Test Data

Input Data. The Test Flow uses data to input into an application.

Verification Data. The Test Flow uses verification data to check Confirmation screen. Data could be hard-coded or combination of hard-coded and input data.


1. GUI observation. “Login screen exists and enabled”.

2. GUI observation. “Username input box exists and enabled”.

3. GUI interaction. “Type in username”.

4. GUI observation. “Password input box exists and enabled”.

5. GUI interaction. “Type in password”.

6. GUI observation. “Login button exists and enabled”.

7. GUI interaction. “Click on Login button”.

8. GUI observation. “Confirmation screen appeared”.

9-N. GUI observation. “Expected text was displayed”.


Essentially, this is almost the same as previous. The only, but significant, difference is that the Flow goes beyond the initial screen.

The scope of the Flow is still very limited – a script executing it won’t “see” anything except screen title and 3 GUI objects. For instance, “Cancel” button presented on the GUI screen, will not be noticed or verified by the script. It won’t handle any unexpected pop-up dialogs, but it is instructed to check the Confirmation screen. 


Could be implemented with any type of approach: API hook-up, record/playback, data-driven scripts, and keyword-driven scripts.

Waiting for the Confirmation screen to appear requires proper synchronization.


Light coverage, typical for Smoke/Sanity Acceptance Test Plan.

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.