DPTASM 17: Marriage vs. Extramarital Affairs

This is not good: This is not rare and I have seen this enough. A Product or Project Team procures Test Automation Tool “T”, creates a Test Automation Platform or Framework and automates tests. After sometime, another Product or Project Team, within the same organization or Business Unit, procures Test Automation Tool “T”, creates a Test Automation Platform or Framework and automates tests. Then, after sometime, another Product or Project Team procures Test Automation Tool “T”, creates a Test Automation Platform or Framework and automates tests. And, what I have observed is this. The needs of these Product or Project Teams in the space of Test Automation are more or less identical in terms of tool, technique and technology. Moreover, at a fundamental level, there are only a few mainstream primary Design Patterns (Test Automation Framework Designs) available and required.

Again, at a fundamental level, the needs of the Product or Project Teams in question may not really vary so much that each team absolutely needs to create its own piece of infrastructure instead of reusing one already created or agreeing on arriving at a common infrastructure that caters to all the needs of all the teams involved. What probably happened here was this. The responsible people in every Product or Project Team wanted to feel the thrill of creating a new piece of infrastructure. Creating a new piece of infrastructure resembles an adventure. They, probably, did not want to invest their energy on finding out what was already available to satisfy the purpose in hand. Finding out what is already available resembles exploration. And, of course, I agree with you that the desire to feel the thrill might not be the only reason. Absence of exploration may possibly lead to absence of awareness about: 1. Existence of something similar and 2. Existence of something reusable.

Here is a question that I would like to ask. What is really more beneficial for an organization in this specific scenario: Adventure or Exploration? And, I clearly understand the thrill associated with any adventure and creating something, really or just apparently, new or different while it may not be, in real terms, new or different at a fundamental level.  At what cost do those teams manage to feel the thrill of reinventing the wheel? And, what is the real need at the enterprise level? Let’s differentiate between wants and needs to cater to the later. That’s the way to remain agile, cost effective, reliable and stable when it comes to Test Automation at an enterprise level. It’s about choosing between a marriage and extramarital affairs.

Marriage vs. Extramarital Affairs: I have spoken about this aspect, may be on a lighter note, over many forums at which I spoke about DPM’s Productized Test Automation Service Model. I do not, however, claim that this, anyway, is the best analogy to use to explain this concept. It’s just my thought. It’s a marriage at the enterprise level versus extramarital affairs at the Product or Project Teams level, when we look at it from the organization’s point of view. A marriage is more about commitment, loyalty, agreements, adjustments, permanence, predictability, consistency, trust, integrity, rules, understanding, routine, discipline, focus on the bigger picture, long term. Here, there is lesser variability and more reuse. Extramarital affairs are adventure, thrilling and exciting, in general. Here, there is freshness and lesser degree of reuse. Here, it is more about randomness and short term. And, of course, it comes with its share of risks and costs. Let’s take a closer look at marriage, at the enterprise level, in the next section.  Next Page >>