Don’t Fear, Testing Team! DevOps is here!

I love Gene Kim’s analogy about how all unicorns used to be horses; its  a great visual that I use all the time when encouraging IT organizations to change from thinking “why not” to “why not us” when it comes to starting their DevOps transformation.  If culture is really one of the greatest enemies to faster adoption, then you have to start with where the horses live.

One of the biggest herd of horses in every organization is the team of people dedicated to testing and validating applications.  Even though these teams are not being included in the conversation, they are in fact the most pivotal part in the transformation.

A Dangerous Love Triangle

DevOps is touted as the marriage of development and operations; a match made in heaven.  One small problem though:  in most traditional organizations there is a love triangle between operations, development, and testing, as the flow of bits roll from one team to the other until the application is delivered to production.  With the conversation shifting to how can development and operations work better together the testing teams are being alienated.  The question is where does a testing team fit into this conversation, when the focus is all about bringing development and operations closer together?  How can the testing team assert themselves to help facilitate this transformation?

Horn Growing Engagement

The Phoenix Project is a great narrative that introduces robust DevOps concepts.  One cannot go far on DevOps.com without seeing “The Three Ways” and what they mean.  The first “way” is about getting a really good understanding of the delivery chain and how it works as a whole to deliver applications to the end user.  The team that knows the most about this is the testing team as they are the glue that binds operations and development together. If you are going to start growing a horn, you need to start here.

Engage with the testing team early and often.  This team knows more about the flow of information from development to production than any other team.  They understand the process of moving applications from development environments, testing them, and delivering them to production. They understand the infrastructure and how it should work and what operations team needs to deploy applications.  This knowledge is the perfect horn-growing fertilizer.

Performance-Driven Feedback

In my last post I talked about how performance and change management were two pillars to start building on.  As you start to move from simply understanding the system as a whole and increasing the rate of feedback, performance data is critical.  Remember, in science there is no right or wrong answer – only data that says the outcome is desired or not. Performance data can help take the emotion out of determining whether or not processes are going right or wrong after change is made.  Most of the performance engineering folks are embedded in the testing groups since this type of expertise is needed to drive a successful DevOps transition. However, be careful as you start to utilize these resources as they have the potential to become your biggest constraints.  Protect them and get the mechanics of performance testing and engineering out of their head and into the heads of your development and operations teams.

Continuous Experimentation

Once you have the testing team on board and helping in this process an interesting event should occur.  The testing teams will start to embed themselves into Development and Operations.  This is when an environment of experimentation becomes possible, just like in a factory, quality is being tested continuously. This leads to a more combined focus on the task at hand while ensuring the quality of the applications and the speed of delivery.

So really the phrase should be: DevOps, don’t fear! The testing team is here!

 

About the author  ⁄ Stephen Wilson

Stephen Wilson

Steve Wilson has over 15 years in individual and management roles that focus on application of technology to business strategy. He currently holds the role as Technical Evangelist for Compuware APM. His experience in working with companies from all industries, in both the development and operations areas, give him keen insight into cross-organizational performance challenges. With these credentials, Steve brings an innovative perspective and insight into IT and business collaboration across the entire lifecycle of an application.

3 Comments

  • Reply
    Matt
    April 2, 2014

    Wow – great post Steve. You have a fantastic knack for summarizing complex ideas into very easy to consume stories. For a guy who is out in the world talking to companies about DevOps and the evolution of IT – this is a great resource. I think I’ll just print your stuff from now on and hand it to people instead of talking : ). Keep the good stuff coming!

  • Reply
    Franco
    April 7, 2014

    I enjoyed the article Stephen. I don’t think that the term DevOps is meant to exclude Testing or QA teams at all. IMO the article is a validation for what many organisations have thankfully come to figure out for themselves. That is, the Testing teams are or need to be part of the DevOps team. The organisations I work with refer to the “Dev” function as the Developers, the Testers and in some cases the Release teams. In some cases the Dev and Test teams are part of the same team Org structure.

    Ultimately the DevOps movement (or whatever you choose to call it in your own organisation) is meant to achieve the following important business outcome…………

    “Meeting market demands for delivery of innovative new application services, doing this faster and at a lower cost without compromising on quality.”

    So I don’t think the question is really as the author suggests “How can the testing team assert themselves to help facilitate this transformation”, I think it’s a given they must be part of the DevOps team. I think the real question is…..

    How can enterprises accelerate the delivery of innovative capabilities and new applications and services to the market, while at the same time reducing the complexity, inefficiency and errors inherent to their existing application deployment processes?

    The answer which certainly includes DevOps must also include as part of DevOps a release automation solution that enables continuous delivery and helps transform the application release deployment lifecycle. Otherwise you are simply moving the application release bottleneck.
    Full disclosure – I work for CA Technologies http://www.ca.com

Leave a Comment

CAPTCHA Image
*