DUCOA 06 - Which classical Test Automation Framework is it based on?
DPM’s UI Control Oriented Abstraction (DUCOA) Test Automation Framework is a Test Automation Framework design built on top of the Keyword Driven Framework and Data Driven Framework. Since it is built on top of the existing knowledge and techniques pertaining to Test Automation Frameworks, in general, and Keyword Driven and Data Driven Framework Designs in particular, I would consciously try to avoid, as much as possible, discussing about the obvious concepts, techniques and details related to those (Example: Error Handling).
A few more things that I am consciously trying to avoid discussing here are: Integration with Build Process and Infrastructure, Integration with Configuration Management or Version Control Process and Infrastructure, Integration with Test Management Process and Infrastructure etc. These aspects or pieces, together, form the Test Automation Peripheral Infrastructure. However, I shall try my best to stick to the core or heart of DUCOA Test Automation Framework (Test Automation Core Infrastructure) and attempt to explain it in as much details as possible.
I chose to maintain silence on the UI Map or GUI Map or Object Repository part in the context of DUCOA Test Automation Framework. I believe, you are the best judge to take a good decision and deliver a verdict about it in your own context. And, there are a couple of reasons to it.
1. Implementation of the UI Map or GUI Map or Object Repository could be very specific to the Test Automation Tool or Infrastructure in use in your own context.
2. In the context of just one Test Automation Tool or Infrastructure too, there are multiple ways to deal with the UI Map or GUI Map or Object Repository and Object Recognition or UI Control Recognition aspects.
3. There may be specific constraints, advantages, facilities, features pertaining to UI Map or GUI Map or Object Repository and Object Recognition or UI Control Recognition aspects specific to the Test Automation Tool or Infrastructure in use in your own context.
I had a choice to integrate the strengths of the Classical Data Driven Framework, instead of Abstracted Data Driven Framework, into DUCOA Test Automation Framework. However, when I did some Design-Experiments to ascertain the feasibility, I came across some interesting results. My results indicated that, integrating Classical Data Driven Framework design into DUCOA Framework Design will:
1. Increase the complexity on the implementation and deployment fronts. (Disadvantage)
2. Make maintainability of Test Automation Infrastructure or Framework more challenging and time-consuming. (Disadvantage)
3. Make maintenance, enhancement, expansion operations on Test Automation Infrastructure or Framework more error-prone. (Disadvantage)
4. Make troubleshooting more difficult and time-consuming. (Disadvantage)
5. Make analysis of Test Run Results more difficult and time-consuming. (Disadvantage)
6. Make the Test Automation Infrastructure or Framework in question more difficult to understand for someone new to the Test Automation Infrastructure or Framework. (Disadvantage)
7. Make the Delivery Cycle (Test Automation Engineers to Users of Automated Tests) and the Translation and Composition Process (Manual Test to Automated Test) lengthy or more time consuming. (Disadvantage)
8. Reduce the number of Translated and Composed Tests only in case of tests that are truly Data Driven. (Advantage). Next Page >>
DUCOA 06 - Which classical Test Automation Framework is it based on? by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
A few more things that I am consciously trying to avoid discussing here are: Integration with Build Process and Infrastructure, Integration with Configuration Management or Version Control Process and Infrastructure, Integration with Test Management Process and Infrastructure etc. These aspects or pieces, together, form the Test Automation Peripheral Infrastructure. However, I shall try my best to stick to the core or heart of DUCOA Test Automation Framework (Test Automation Core Infrastructure) and attempt to explain it in as much details as possible.
I chose to maintain silence on the UI Map or GUI Map or Object Repository part in the context of DUCOA Test Automation Framework. I believe, you are the best judge to take a good decision and deliver a verdict about it in your own context. And, there are a couple of reasons to it.
1. Implementation of the UI Map or GUI Map or Object Repository could be very specific to the Test Automation Tool or Infrastructure in use in your own context.
2. In the context of just one Test Automation Tool or Infrastructure too, there are multiple ways to deal with the UI Map or GUI Map or Object Repository and Object Recognition or UI Control Recognition aspects.
3. There may be specific constraints, advantages, facilities, features pertaining to UI Map or GUI Map or Object Repository and Object Recognition or UI Control Recognition aspects specific to the Test Automation Tool or Infrastructure in use in your own context.
I had a choice to integrate the strengths of the Classical Data Driven Framework, instead of Abstracted Data Driven Framework, into DUCOA Test Automation Framework. However, when I did some Design-Experiments to ascertain the feasibility, I came across some interesting results. My results indicated that, integrating Classical Data Driven Framework design into DUCOA Framework Design will:
1. Increase the complexity on the implementation and deployment fronts. (Disadvantage)
2. Make maintainability of Test Automation Infrastructure or Framework more challenging and time-consuming. (Disadvantage)
3. Make maintenance, enhancement, expansion operations on Test Automation Infrastructure or Framework more error-prone. (Disadvantage)
4. Make troubleshooting more difficult and time-consuming. (Disadvantage)
5. Make analysis of Test Run Results more difficult and time-consuming. (Disadvantage)
6. Make the Test Automation Infrastructure or Framework in question more difficult to understand for someone new to the Test Automation Infrastructure or Framework. (Disadvantage)
7. Make the Delivery Cycle (Test Automation Engineers to Users of Automated Tests) and the Translation and Composition Process (Manual Test to Automated Test) lengthy or more time consuming. (Disadvantage)
8. Reduce the number of Translated and Composed Tests only in case of tests that are truly Data Driven. (Advantage). Next Page >>
DUCOA 06 - Which classical Test Automation Framework is it based on? by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Comments
Post a Comment