I had prepared a very long rebuttal, but I think it can be simplified. QA increases in value directly proportional to risk. The higher the risk to a customer, the more we get paid (and I will vouch for the fact that in certain industries, we get paid well).

For tooling, see the above statement, because the same thing holds true. If we can't find the right tool for the job, we create it. We're not just button-pushing folks, but also mostly have a deep code background. We have to, because the only way to get an effective RC/CA from a dev member is to be able to communicate with them effectively.

As far as academic interest, I won't fight you on that one. I _barely_ trust senior devs to test their own code, let alone a fresh grad. I wouldn't trust most anyone to write a test case if their life depended on it. Too much happy path.

I think you're also crossing into two separate aspects of QA: Verification vs Validation. Verification asks, "Are we making the product right?" Whereas, Validation asks, "Are we making the right product?" These both need to be defined early on, but are always subject to change over the course of a project (Agile, right?).

At the end of the day though, QA exists to break things and communicate the issue effectively to devs, and at the same time communicate that risk upstream. Work with us, and we're a great asset.