QA Automation – GUI Function Wrapping

Some of the statements below will be covered in detail in my subsequent posts. Now I use them to get straight to Test Step requirements.
Please read details below the picture.

Quality Assurance Functional/Regression Automated Testing and Test Automation Requirements: Usability, Maintainability, Scalability, and Robustness.

Let’s break them down now for implementation of a single GUI Step.

Usability / Coverage

Test Step encapsulates verification of GUI Object and Test Data.

GUI Object verification includes.

Accessibility
• If the Object is defined by logical name, its description is available in Repository.
• If the Object is defined by description, Object’s Parent can return Object Instance.
• Object Instance is not empty ( != NULL).

Availability
• The Object must EXIST on the GUI (and this is enough for the Property Read operation).
• For input-type operation the Object must be ENABLED.
• For Screen Read operation the Object must be DISPLAYED.

Test Data verification includes acceptability by an Object and DOES NOT include any business validation. If Application Under Test for whatever the reason didn’t like the input, it brings error message or other response, that is captured, (optionally) analyzed, and reported by the automated testing system.

Acceptability

• Number of arguments provided must match number of arguments that Object’s method can accept.
Example. To select a cell on a table both row and column must be provided.
• Type of arguments to pass in matches type of arguments Object’s method can accept.
Example. To select a cell on a table row number and column name must be provided.
• Type of supplied data matches types that Object’s method can accept
Example. A CheckBox accepts only 3 values that define possible states of it: ON, OFF, or DIMMED

Robustness

Synchronization, error and exception handling provide stable and unbreakable test flow.

Synchronization
• If specified, the Test Step Function should wait for the Object reaching defined state (E.g. EXISTS, ENABLED, DISPLAYED) within default or defined timeframe.

Error handling
• In case of failed operation caused by any matter verification code handles the error, and provides recovery and negative reporting.
• In case of unexpected AUT response (I.e. Pop-up Dialog) exception handler catches it, handles, and passes control back to the targeted GUI Parent form.

Usability / Investigation and Reporting

Test Flow reporting provides end-user with the complete and detailed information, and that allows reproducing even without manually going through the Test Case. Reporting of Object and AUT status description, Test Data log, and judgments made serves that purpose.
In case of failures investigation should be performed, by capturing state of application-under-test, GUI form and GUI object, isolating and reporting properties of the mentioned components.

Description
• In case of Negative Reporting, description provides the reason of the FAIL.
Example 1. Failed to input value. Object is not enabled.
Example 2. Failed to select list item. Item does not exist.
• In case of Positive Reporting, description provides details about the operation performed.
Example 1. Pressed button.
Example 2. Retrieved object data.

Data log
• Data used in input, retrieval or verification are provided to the end-user.

Judgments
• Describe PASS condition used.
• Describe FAIL condition used.
• Describe Cut-Off condition (timeout, boundaries, etc.) used.

Finally, you can see below an example of the Actual Test Report generated after the execution of several GUI steps (business data scrambled).