DUCOA 01 - DUCOA Test Automation Framework
A Little Background:
A few years back (in early 2007), I had conceptualized and created a white paper on DUCOA Test Automation Framework (A generic framework design for GUI based Software Test Automation). However, I never published it. May be, I was too lazy to do that! Now, while I work on yet another Test Automation project, I wanted to dust it off and publish it for the obvious reason. It took me a lot of time to find the document that I had created many years back. And, I am glad that I eventually managed to find it, enhance the idea in it and add a few more concepts to the base idea. Since I published it, now I stand a good chance of receiving some useful feedback about it. It looks like, I can really use this Test Automation Framework Design in the Test Automation project I am currently working on. I have been associated with Software Product Test Automation since 2002. In this whitepaper, I have tried to put together all that I have seen, learnt and experienced in this space.
The Important Questions:
This Test Automation Framework Design is probably my answer to these below listed questions that I had in my mind for a long time.
1. Is there a way to break the technology barrier so that Software Test Engineers (who are, as such, not Software Test Automation Engineers) can create Automated Tests?
7. Is there a way to make available, in just one unified mechanism, all the Essential and Powerful Capabilities (Features) really required to build a large-scale and sustainable collection of automated software tests?
8. Can that unified mechanism encourage and strengthen System Thinking, Design Thinking, Model Thinking and Problem Solving in the users of the mechanism?
 |
| Submarine Software Test Automation Platform |
The Important Questions:
This Test Automation Framework Design is probably my answer to these below listed questions that I had in my mind for a long time.
1. Is there a way to break the technology barrier so that Software Test Engineers (who are, as such, not Software Test Automation Engineers) can create Automated Tests?
2. Is there a possibility that those Software Test Engineers can create Automated Tests in a very familiar environment in which pretty much everything, including Tests, Components, Configuration, Test Data and Objects Description, is human readable and editable outside the test automation tool?
3. Can they do that without needing to learn a programming or scripting language and the features of a typical Test Automation Tool?
4. Is it possible to provide a multilevel abstraction so that the inherent complexity becomes transparent to the end user?
5. Is there a way those Software Test Engineers, who know the domain, the users, the product, the workflows, the functionalities and which areas in the application are more susceptible really well, can apply their strengths in creating powerful, meaningful and valuable Automated Tests?
6. Is there a way to explicitly focus on, and consciously build, generic Software Test Automation Competencies of a significantly higher maturity level, instead of creating specific Competencies around specific Test Automation Tools?
8. Can that unified mechanism encourage and strengthen System Thinking, Design Thinking, Model Thinking and Problem Solving in the users of the mechanism?
The Thoughts:
I believe, in most of the cases, those Software Test Engineers engaged in the Product, System and User Acceptance Testing of a Software Product or Application are in a better position, compared to the typical Software Test Automation Engineers, in deciding what tests need to be automated (Risk Based Selection), why (Value Based Selection) and what is the best way to do so (what validations needs to be included, what should be the exact sequence of actions and verifications within a test etc.). And, they (those Software Test Engineers), better, should not be bothered with the inherent technical complexities and challenges of Software Test Automation. There must be a simple, reliable and flexible mechanism at their disposal to create powerful and valuable Automated Tests, seamlessly.
The only thing they should really need to learn is the set of generic techniques pertaining to Software Test Automation, and nothing else, pretty much. I think, a good Test Automation Framework should allow creation of powerful, meaningful and valuable Automated Tests also by those users who do not have any knowledge and experience in Test Automation Tools and Programming or Scripting Languages, as such. It must be possible for an organization to do Test Automation sustainably without deploying expensive skills in that area of activities. And, a good Test Automation Framework should be built as a Platform that allows extreme reuse. The DUCOA Test Automation Framework is probably an answer to all the above questions and a reflection of all the above thoughts.
Before I go ahead, here is a general thought. A Test Automation project is like a wrestling match where winning takes not only great brute force, but it also takes fine techniques mastered. Mastering that takes adequate preparation and planning. This preparation in the context of a Test Automation Project, to a great extent, is the test Automation Framework (Infrastructure) you create and go ahead with! Before you delve deeper into the details, you may want to take a quick look at the DUCOA Summary.
What does this framework change in the world?
1. It significantly changes the way Software Product, System and User Acceptance Test Engineers contribute in the context of their work and progress in their careers.
2. It also generates a substantial positive impact on the Cost, Schedule, Sustainability and Quality of test automation, in general, in the context of Software Product, System and User-Acceptance Testing.
Note: DUCOA is NOT an off-the-shelf 'ready to use' Test Automation Framework or Tool. DUCOA is more about a Generic Design Philosophy and Architecture (combined with certain Good Practices) that you may use to create your own tangible Test Automation Framework using the Technology, Programming Language and Test Automation Tool or Infrastructure of your choice. I am sure, when I get a product created based on the generic DUCOA Design, it is going to have a big bunch of features which lets the users of that product benefit from the full potential of DUCOA Design. And, for sure, it's not really going to be about a Test Automation Tool. It is going to be really about hardcore Test Automation. At an enterprise level, an organization can derive substantial benefits and reduce cost of Software Test Automation drastically by applying DUCOA Architecture and Design in deploying DPM’s Productized Test Automation Service Model (DPTASM). In case you have a question about this Test Automation Framework Design, please feel free to get in touch with me.
What is it all about?
DUCOA "Architecture and Design" philosophy is built on the idea that Test Automation must be Simple, Extensible, Scalable and Maintainable. In that context, DPM’s UI Control Oriented Abstraction (DUCOA) Test Automation Framework design encompasses two important aspects:
1. Multiple Layers of Abstraction
2. Primary focus on User Interface (UI) Controls
Let’s take a closer look at these two aspects. In the context of Functional Testing (Product, System and User Acceptance etc.), which is the context of Test Automation in most of the cases, we do not test the Software (SUT = Software Under Test) as such. What I mean over here is, we do not test the Software in terms of the technology it is built with, the programming language used to develop it, the technical platform it is built on top of etc. What we really test are the functionalities of the software (SUT) and its performance.
In most of the cases, we test the workflows or use-cases or business-cases or scenarios that realistically represent the end-users’ interaction with the SUT. And, each workflow usually involves interaction with multiple instances of GUI Elements, Windows, Pages and Screens of the Software Under Test (SUT). And, those instances of interaction usually involve interaction with multiple UI Controls or GUI Objects in a specific sequence or order. Instances of GUI, Windows, Pages and Screens, in that sense, are examples of UI Controls or GUI Objects. Let's take a look at the Abstraction Layers, next.
UPDATE (2017): Over the course of the past years, we have re-branded the software test automation platform created on the basis of the DUCOA Test Automation Framework Design as the Submarine Test Automation Platform and have got five cumulative versions created: Submarine Attempt, Submarine Basic, Submarine Classic, Submarine Distributed and Submarine Enhanced. I would like to take this opportunity to sincerely thank the primary contributors and the valuable supporters - Global R&D Partners, Local Management Representatives, Colleagues who have supported the development of Submarine in various ways, the Key Users and many other colleagues and users across the global R&D sites. This has indeed been a wonderful journey. Next Page >>
DUCOA 01 - DUCOA Test Automation Framework by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
I believe, in most of the cases, those Software Test Engineers engaged in the Product, System and User Acceptance Testing of a Software Product or Application are in a better position, compared to the typical Software Test Automation Engineers, in deciding what tests need to be automated (Risk Based Selection), why (Value Based Selection) and what is the best way to do so (what validations needs to be included, what should be the exact sequence of actions and verifications within a test etc.). And, they (those Software Test Engineers), better, should not be bothered with the inherent technical complexities and challenges of Software Test Automation. There must be a simple, reliable and flexible mechanism at their disposal to create powerful and valuable Automated Tests, seamlessly.
The only thing they should really need to learn is the set of generic techniques pertaining to Software Test Automation, and nothing else, pretty much. I think, a good Test Automation Framework should allow creation of powerful, meaningful and valuable Automated Tests also by those users who do not have any knowledge and experience in Test Automation Tools and Programming or Scripting Languages, as such. It must be possible for an organization to do Test Automation sustainably without deploying expensive skills in that area of activities. And, a good Test Automation Framework should be built as a Platform that allows extreme reuse. The DUCOA Test Automation Framework is probably an answer to all the above questions and a reflection of all the above thoughts.
Before I go ahead, here is a general thought. A Test Automation project is like a wrestling match where winning takes not only great brute force, but it also takes fine techniques mastered. Mastering that takes adequate preparation and planning. This preparation in the context of a Test Automation Project, to a great extent, is the test Automation Framework (Infrastructure) you create and go ahead with! Before you delve deeper into the details, you may want to take a quick look at the DUCOA Summary.
What does this framework change in the world?
1. It significantly changes the way Software Product, System and User Acceptance Test Engineers contribute in the context of their work and progress in their careers.
2. It also generates a substantial positive impact on the Cost, Schedule, Sustainability and Quality of test automation, in general, in the context of Software Product, System and User-Acceptance Testing.
Note: DUCOA is NOT an off-the-shelf 'ready to use' Test Automation Framework or Tool. DUCOA is more about a Generic Design Philosophy and Architecture (combined with certain Good Practices) that you may use to create your own tangible Test Automation Framework using the Technology, Programming Language and Test Automation Tool or Infrastructure of your choice. I am sure, when I get a product created based on the generic DUCOA Design, it is going to have a big bunch of features which lets the users of that product benefit from the full potential of DUCOA Design. And, for sure, it's not really going to be about a Test Automation Tool. It is going to be really about hardcore Test Automation. At an enterprise level, an organization can derive substantial benefits and reduce cost of Software Test Automation drastically by applying DUCOA Architecture and Design in deploying DPM’s Productized Test Automation Service Model (DPTASM). In case you have a question about this Test Automation Framework Design, please feel free to get in touch with me.
What is it all about?
DUCOA "Architecture and Design" philosophy is built on the idea that Test Automation must be Simple, Extensible, Scalable and Maintainable. In that context, DPM’s UI Control Oriented Abstraction (DUCOA) Test Automation Framework design encompasses two important aspects:
1. Multiple Layers of Abstraction
2. Primary focus on User Interface (UI) Controls
Let’s take a closer look at these two aspects. In the context of Functional Testing (Product, System and User Acceptance etc.), which is the context of Test Automation in most of the cases, we do not test the Software (SUT = Software Under Test) as such. What I mean over here is, we do not test the Software in terms of the technology it is built with, the programming language used to develop it, the technical platform it is built on top of etc. What we really test are the functionalities of the software (SUT) and its performance.
In most of the cases, we test the workflows or use-cases or business-cases or scenarios that realistically represent the end-users’ interaction with the SUT. And, each workflow usually involves interaction with multiple instances of GUI Elements, Windows, Pages and Screens of the Software Under Test (SUT). And, those instances of interaction usually involve interaction with multiple UI Controls or GUI Objects in a specific sequence or order. Instances of GUI, Windows, Pages and Screens, in that sense, are examples of UI Controls or GUI Objects. Let's take a look at the Abstraction Layers, next.
UPDATE (2017): Over the course of the past years, we have re-branded the software test automation platform created on the basis of the DUCOA Test Automation Framework Design as the Submarine Test Automation Platform and have got five cumulative versions created: Submarine Attempt, Submarine Basic, Submarine Classic, Submarine Distributed and Submarine Enhanced. I would like to take this opportunity to sincerely thank the primary contributors and the valuable supporters - Global R&D Partners, Local Management Representatives, Colleagues who have supported the development of Submarine in various ways, the Key Users and many other colleagues and users across the global R&D sites. This has indeed been a wonderful journey. Next Page >>
DUCOA 01 - DUCOA Test Automation Framework by Debi Prasad Mahapatra is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Good One -Brijesh
ReplyDeleteThank you, Brijesh.
DeleteNice thought.
ReplyDeleteThank you, Audumber.
Delete