Testing as an essential dependency for DevOps

This post is a response to and a comment on my colleague Paul Peissner’s blog: Expanding QA and Tester Role in the DevOps IT Era?  One of Paul’s primary points in that blog post is:
“To enable business agility, IT needs to grow QA's value, role and function, this will help with better job estimating but more importantly it will drive the right long-term response by IT when surprises hit.”
In my observation, the mission and purpose for QA professionals is far more important in the DevOps model -- QA professionals strive to proactively improve the probability of delivering a higher quality product, a more innovative product. Also, I want to correctly label DevOps as not a cultural movement; DevOps is simply a change in approach or method to delivering a product.
Part of the impetus to adopt DevOps is the pressure on business leaders to be more profitable and more responsive to market demand, through innovation. Thanks to IDEO and David Kelley, those business leaders have been sold on an idea of innovation as a product, even though I think most of them actually have a preference for profitability over innovation. But we all might agree that improving the quality of our innovative thinking is an integral part of how we build successful products. From my experience as both a tester and a product manager, I know the benefits of improved quality in products and the correlated reduction in risk to failure of the product.  And I know the importance and pressure to deliver high quality innovations and differentiation, if you hope avoid failure of the idea.
What does this have to do with DevOps?  To become more innovative, the Web Operations sub-team in IT Ops started picking up more and more “innovative” skills and recruiting web developers and super-administrators to merge onto the same team so they could move faster and be more innovative. Just being a system administrator (who keeps the monthly release train wheels turning and the gears oiled) isn’t good enough enough anymore – the business needs “more responsiveness” from you.  And just being a developer engineer waiting for requirements and specifications isn’t responsive enough either – the business needs “more innovative problem solving” from you. What happens when you start to ask a bunch of developers and system administrators to stop focusing on the product development machinery and start contributing to innovation, ideas, and responsiveness? The wheels can come off.
If this self-proclaimed DevOps movement is to provide any positive change for our industry and to the businesses we serve, then I think it’s important to recognize three underlying origins for DevOps and reflect on how QA can get involved:
Vendor Agnosticism: as a web site or system administrator being pressured to innovate working with new ideas, tools, and stuff – you might turn first to the vendors you already work with. In some cases, if there is resistance to DevOps “cultural immaturity” and a lack of DIY skill some folks might cling too tightly to their vendors as a safe-haven. As a tester, you might log a bug against an incomplete process or limitation of benefit caused by vendor-bias or preference. If the quality of your product is going to suffer because there was a top-down mandate to use ‘Vendor Product X’ or ‘Vendor Product Y’ then QA should log a bug against that biased decision or perceived mandate.
Organic Collaboration: as a tester who tries to conserve the practices that successfully find bugs and secure the high-quality standard for product development, it’s natural to question anything new and “innovative” (quotes emphasized). The idea of new can also mean higher risk of the unknown impacts on quality. This means testers are perceived as conservatives or “keepers of the old” while this new DevOps-y adoption may be perceived as risky or “leading the wrong way.” No matter the perceptions we have, we need to work together to deliver something. If the quality of the product is going to suffer because certain groups "just don't get along" then QA should log a bug against the people who aren't collaborating. Yes, it's a defect to be willfully uncooperative.
Rationalization of Failure: as a business leader investing in technology as a future for the corporation, failure is definitely not preferred -- and as shareholders, we really don’t like failure either. However, failure and recovery is now becoming an accepted and even preferred mode for operating. But if the quality of the product is at risk because we are over-accepting failure in any part of the process from inception, definition, stories, coding, automation, builds, performance, security, tools - then we should log a bug against the policy (or lack of a policy) around failure.
I agree with Paul that with the adoption of DevOps practices, testers have new kinds of bugs to find, new bugs around policies on failure, organizational cooperation and unethical vendor biases.
The opportunity for testers is to expand our scope to include both products and ideas. We can bring a professional rigor to testing ideas and innovations prior to their instantiation and forecasting into product revenue or application. We can re-emphasize our role as testers of ideas and testers of innovation, testers of risk and value.
Unfortunately, what I often see is that testers are regarded as just technical bug hunters, as servants to the code or system. This treatment stems from a limited consideration for the mind's capability to engage holistically in the creative process for the very innovation we seek. In this new world where QA is a part of DevOps, then, if you limit the role of the tester, you are inherently limiting the benefits, the innovations, and the responsiveness of DevOps.