DPTASM 01: DPM’s Productized Test Automation Service Model
A Little Background: I mean reduction in cost to an extent of 20% to 70% at the enterprise level when I say “reduce cost of Test Automation drastically”. Yes, up to 70%! And, that’s not it. It’s also about a 30% to 70% decrease in “Time to the End-User”, a 15% to 65% gain in productivity and an impressive 25% to 75% increase in quality. Software Test Automation is inherently an expensive and complex business! With DPM’s Productized Test Automation Service Model (DPTASM) in place, reduced complexity and 'time to user', increased productivity and quality are achieved at a drastically lower cost. And, all this without any further massive investment in infrastructure. So, if that sounds good enough, you may take a serious look at this model. It’s fundamentally about moving to a higher Maturity Level in the context of Test Automation at an enterprise level. I am going to write in detail about Test Automation Maturity Model in one of my subsequent whitepapers.
One of the primary goals of DPM’s Productized Test Automation Service Model (DPTASM) is to reduce cost of Test Automation drastically at an organizational level and provide a Test Automation Service that is easy to compose, efficient to extend and absolutely simple to deliver.
The Paradigm Shift: A Product or Project Team’s attempt to own an 'Automation Engineering and Development Team' and a 'Product or Project Team specific Test Automation Infrastructure' usually makes Test Automation an expensive affair at an enterprise level. This shift in paradigm is about the delta between Exclusive Ownership and Shared Utilization. It is about drastic reduction in cost and massive optimization of infrastructure.
DPM’s Productized Test Automation Service Model (DPTASM) is NOT something that necessarily involves high level of technical complexity, massive investment in infrastructure and investment in hiring additional people with specific premium skills. An organization can work with this model pretty much with its existing infrastructure, people and their skills. And, the complexity of the business in question (Test Automation) remains at a level that can still be managed easily.
When we are talking about “Product and Project Teams across the organization”, we also refer to Product and Project Teams that span across multiple geographies (States, Countries and Continents). This is especially true when it has become an increasingly common situation in which a software product gets developed by teams located across States, Countries and Continents. In this context, DPM’s Productized Test Automation Service Model (DPTASM) can help in establishing Test Automation Competency Centers that can effectively and efficiently serve (Service and Consulting) multiple Product Lines, Projects and Teams irrespective of their respective geographical position, especially in this era of technology and connectivity.
DPM’s Productized Test Automation Service Model (DPTASM) is a part of the original White Paper I wrote on DUCOA Test Automation Framework Architecture and Design a few years back. However, since DPM’s Productized Test Automation Service Model is based, to some extent, on the strengths of DUCOA Test Automation Framework Architecture and Design, I wanted to publish the former after I published the later.
Note: The focus of the whitepaper was on conventional GUI based Test Automation in the context of Sanity, Product, System and Acceptance Testing that, if not automated, are done usually by Software Test Engineers by interacting with the GUI of the Software Product or Application in question. Next Page >>
One of the primary goals of DPM’s Productized Test Automation Service Model (DPTASM) is to reduce cost of Test Automation drastically at an organizational level and provide a Test Automation Service that is easy to compose, efficient to extend and absolutely simple to deliver.
The Paradigm Shift: A Product or Project Team’s attempt to own an 'Automation Engineering and Development Team' and a 'Product or Project Team specific Test Automation Infrastructure' usually makes Test Automation an expensive affair at an enterprise level. This shift in paradigm is about the delta between Exclusive Ownership and Shared Utilization. It is about drastic reduction in cost and massive optimization of infrastructure.
DPM’s Productized Test Automation Service Model (DPTASM) is NOT something that necessarily involves high level of technical complexity, massive investment in infrastructure and investment in hiring additional people with specific premium skills. An organization can work with this model pretty much with its existing infrastructure, people and their skills. And, the complexity of the business in question (Test Automation) remains at a level that can still be managed easily.
When we are talking about “Product and Project Teams across the organization”, we also refer to Product and Project Teams that span across multiple geographies (States, Countries and Continents). This is especially true when it has become an increasingly common situation in which a software product gets developed by teams located across States, Countries and Continents. In this context, DPM’s Productized Test Automation Service Model (DPTASM) can help in establishing Test Automation Competency Centers that can effectively and efficiently serve (Service and Consulting) multiple Product Lines, Projects and Teams irrespective of their respective geographical position, especially in this era of technology and connectivity.
DPM’s Productized Test Automation Service Model (DPTASM) is a part of the original White Paper I wrote on DUCOA Test Automation Framework Architecture and Design a few years back. However, since DPM’s Productized Test Automation Service Model is based, to some extent, on the strengths of DUCOA Test Automation Framework Architecture and Design, I wanted to publish the former after I published the later.
Note: The focus of the whitepaper was on conventional GUI based Test Automation in the context of Sanity, Product, System and Acceptance Testing that, if not automated, are done usually by Software Test Engineers by interacting with the GUI of the Software Product or Application in question. Next Page >>
Comments
Post a Comment