DUCOA 02 - The Abstraction Layers

Here is a diagrammatic representation of the layers of abstraction in DUCOA Test Automation Framework. This is just an attempt to diagrammatically depict the DUCOA Abstraction Philosophy.  This is not really a Design or Architecture diagram. A schematic DUCOA Architecture diagram is available here.

Important: Here is the abstraction mechanism summarized. In the context of the DUCOA Test Automation Framework, we just perform Operations or Actions and Verifications or Checks (and, those are, actions too) on UI Controls or GUI Objects. That, in turn, satisfies execution of the most granular UI Control or Object Level Test Steps of a Composed Test. That, in turn, satisfies the execution of the most granular UI Control or Object Level Test Steps of a Translated Test.

That, in turn, satisfies the execution of steps of The Test. That, in turn, satisfies the testing of a workflow or use-case or business-case or scenario. And, that, in turn, satisfies the functional testing of a Software Under Test (SUT) or Application Under Test (AUT). However, in fact, we just really focus and work on the UI Controls or GUI Objects; and the Software Under Test (SUT) or Application Under Test (AUT) gets tested! Sounds good? (NOTE: What are Translated Tests and Composed Tests by the way? You might have this question at the moment. These are explained in one of the subsequent posts on this Blog. Please stay with me till then. I am sure, it is not making a lot of sense yet. But, it will, soon.)

Based on the DUCOA Philosophy, there are two important parts here: 1. The Layers of Abstraction (That is, The Test Context)and 2. The Test Automation Infrastructure. It is the Test Automation Infrastructure that runs the Test (s), in question, automatically. Ultimately, what it takes to test any workflow is nothing but a set of 'interactions with a set of UI Controls or GUI Objects' (and any other Non-UI Operations). The DUCOA Test Automation Framework just focuses on the UI Controls or GUI Objects of the SUT. In short, this is what is done here.

1. In the first step, all the unique UI Controls or GUI Objects of the SUT (Software Under Test) are identified. We are not talking just about all the UI Controls or GUI Objects of the SUT here. We are just interested in all the TYPES or Classes of unique UI Controls or GUI Objects of the SUT. 

2. In the next step, all the unique Actions (Operations) and Verifications are identified pertaining to each unique TYPE or Class of UI Control or GUI Object.

3. In this step, Automation Code (Functions or Methods Library) is created for each of the unique UI Control or GUI Object specific Actions (Operations) or Verifications.

With this done, the core part of the DUCOA Test Automation Framework is essentially ready. We have this ready and we can use it now. As we discussed earlier, any test is nothing but essentially a specific sequence of interactions with UI Controls or GUI Objects, as far as the UI Interaction part of the test is concerned. Now, we have the Automation Code (Function or Method Library) ready for each of the unique Class or Type of UI Control or GUI Object specific (Operations) or Verifications. To automate a test, we just need to execute or run or exercise these Functions or Methods in a sequence dictated by The Test in question and we are done with automation of the UI Interaction part of The Test! That’s absolutely easy and fast. Isn’t it? Let's take a look at why DUCOA is a good choice, next.  Next Page >>

DUCOA 02 - The Abstraction Layers by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.