Addressing incompatible types during element reconciliation

accelQ makes possible in-sprint automation with intelligent abstraction features at every level. Abstracting out UI element description is one of the important aspects of such abstraction. When you are creating abstract element, you make certain assumptions about the “type” of element, such as a link, input field, dropdown etc. based on the functional knowledge of the application.

In some cases, it may so happen that the actual element type on the UI application may be different than originally thought about. For example, a link may have been actually implemented as a button or an input field may have been implemented as a dropdown. accelQ handles such situations gracefully without breaking any of the test logic. Following situations are possible with change of element type:

1. New element type supports all the operations that were used against the abstract element in the test logic: No change in commands and statements.
2. New element type has a compatible operation for the operations being performed on abstract element: Commands and statements are automatically converted to the new type. For example, entering text in input field (abstract element type) will change to dropdown (new element type) selection operation.
3. New element type is completely incompatible with the abstract element type: Blocking errors are produced during the reconciliation process. User needs to review the operations and make appropriate decisions.