DUCOA 11 - The Use Case: How is this Framework used?

This is how the DUCOA Test Automation Framework is used.

1. A Test Engineer creates a request to get a specific test-case automated. This request, at this step, consists of:

a. The unique representative and meaningful ‘Name’ of the test or test-case.

b. A high-level brief or one-line description of the test-case in question.

2. The Test Engineer breaks that test-case into a set of most granular UI Control or GUI Object Level Action and Verification steps (The Translated Test) that specify, in appropriate cases, the exact UI Control specific Input Data (Entered Text, Entered Value, Selected Combo Box Item, Selected Tree View Item etc.) and Expected Output Data pertaining to exact UI Control (s). This is also a layer of abstraction.

This instance of abstraction allows someone new to the Application under Test, the Domain and the Business Context, fully understand the details of the test by taking a look at the Translated Test. This set of steps is so detailed that no step in this list can further be broken into more Action or Verification steps. This level of detailing offers the following advantage:

a. An absolutely clear definition of the scope

b. An absolutely clear picture of the exact sequence of actions and verifications

c. No open questions pertaining to how to do something in the context of the test in question

d. Test Automation Effort Estimation and Complexity Computation become easier and relatively straightforward

e. And, thus, it becomes easy to identify the test-specific test-automation challenges and bottlenecks in advance

3. The Test Engineer submits the test specific automation request with the Test Automation Engineering or Development Team. The set of most granular UI Control or GUI Object Level Action and Verification steps and the prerequisites for that test (in terms of application state, any specific configuration and data pre-created in the AUT or SUT etc.) are also submitted along with the request.

4. Once this request is received, a detailed feasibility analysis is done by the Test Automation Engineering or Development Team to ascertain if it is possible to automate the test in question. In case the feasibility analysis suggests that the test can't be automated (within reasonable resource limits), the Test Automation Engineering or Development Team communicates that back, with appropriate explanation and clarification, to the source of the request.

5. In case the feasibility analysis suggests that the test can be automated (within reasonable resource limits), the Test Automation Engineering or Development Team takes the set of most granular UI Control or GUI Object Level Action and Verification steps, submitted along with the request, through a process of Composition.

6. In the process of Composition, more details (UI Control or GUI Object Action or Operation and Verification Function Name, UI Control Parameters (to identify, locate or find or discover the UI Control or GUI Object in question), Control Specific Input and Expected Output Data are added. And, many a time, more granular steps (like re-sizing or moving a piece of UI before a specific Test Step to workaround an issue) are added during the Composition process to make it more compatible with the SUT specific Test Automation context. This process results in a Composed Test.

7. The Test Automation Engineering or Development team makes a detailed analysis of the set of most granular UI Control or GUI Object Level Action and Verification steps in the Composed Test to determine if more stuff needs to be added to the Test Automation Infrastructure or Framework to meet any specific requirement rooted in this request (That is, the test to be automated).

8. If the analysis suggests that more stuff needs to be created and added to the Test Automation Infrastructure or Framework, then, the stuff is | are:

a. Created

b. Tested

c. Integrated into the Test Automation Infrastructure or Framework

9. Once the above tasks are accomplished, the Test Automation Engineering or Development team adds the newly composed automated test to the context of the Test Automation Infrastructure or Framework. That results in a new executable and usable automated test! That is, when a new test is automated, an entry for that test is added to the Test Driver File and the related Composed Test is added to the set of existing Composed Tests.  Next Page >>

DUCOA 11 - The Use Case: How is this Framework used? by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.