How do you respond to comments that Testers are simply failed Developers and QA is a 2nd rate IT practice?  I am not sure there is a more politically incorrect, offensive, small-minded and divisive statement in IT and across the software community....

If you look at the IT history of Enterprise QA (post-Mainframe and pre-Modern - i.e. before Cloud / SOA / Open-Standards / Open-Source / Virtualization / Automation / Agile / DevOps), what you would see is a 30+ year sprawl of non-standards IT and non-compatible technology. I call it the era of...

1. - proprietary platforms/products/tools,
2. - intentional vendor-lock designs,
3. - exclusivity-driven optimization and
4. - industry-driven political non-compatibility.

Silo innovation came with a heavy IT price tag! There was religious-like enthusiasm with different IT disciplines in their silos as they explored and promoted "self-serving silo-specific optimization" and specialty practices with little or no regard for the impact (or additional costs it would eventually have) on other IT disciplines or its performance impact on the interdependent IT infrastructure, support or businesses it was supposes to served. 

The Enterprise quickly developed 2 practices to ensure a "minimal" level of "Application-level" (IT Asset-level) quality and IT collaboration.  Because IT was in a chaotic time when they could not afford to pick a single IT vendor's Hardware, Network, OS, client/end-point device standards, code-languages, etc...leading technology vendors released silo-appealing features that would give their brand a Silo advantage over it's competitors..... ITIL (in Ops) and QA (in Apps) were the only places where silo decision-making IT groups where held accountable for the "overall" impact they had to business services. 

Overnight, QA became the global hero for IT practices that had gotten so decentralized that the IT silos (including development) started rewarding isolated contributions and niche expertise with little accountability of long-term cost, compounding-complexities and sustainability. In many ways QA and the decision-making control they were given helped many organizations through this chaotic season of Technology changes and the exclusive standardization of Waterfall projects (high-risk projects of 3-yr cycles, millions of code-lines, 1000's of features, 100's of developer pockets...pushing out Mega-Apps in IT Operational environments that were undergoing dramatic changes every 24 months). In some cases QA held the only working IT knowledge of what was a show-stopper App and what was an optimal App for the IT team to manage. 

However, today IT is now being held accountable to be more cost-effective, more collaborative, more accountable and to "partner with the business" to make better long-term decisions earlier and all-the-way-through the IT process. QA knowledge and expertise is critically needed in… 1)    development’s adoption of test-driven agile development best-practices, 2)      more of IT’s quality-standards setting, 3)      automated release processes (and their continuous improvement), and 4)      defining Ops standards for quality, security, performance or user disruption especially with the growing practice of modern Canary Testing strategies.

Today's QA experts do need to expand their knowledge beyond legacy and waterfall-only QA tools and practices to help right-size QA for modern projects with tools and practices per the nature of the...

1. Project's risk and business benefit factors...
   
2. Developer teams past skills, re-usable resources, expertise, success...
3. Project size, methodology, timeline and legacy-orientation,
4. Operations and Deployment's standardization on Cloud, Virtualization, Automaton, etc.
   
5. IT service and business impact potential and needs (short & long-term).

In my opinion, comments about testers "failed" developers and QA being 2nd rate IT contributors... usually comes from silo-era (and small minded) developers and IT staff members, that have little knowledge of our IT history or of their long-term potential to harm the business with their "innovative" contributions.

There are many in the Vivit community that would be happy to walk with IT teams (Apps & Ops co-workers) that need to improve collaboration to enable "business competitive agility" and how to spend less time, money and energy fighting about silo-era levels of importance.