Automating processes is a double-edged sword. As one wit put it "It makes mistakes faster than ever!". 🙂
And yes, managers ALWAYS view automation as a way to cut payroll. Full stop. No exceptions. Mostly because it's true. As a result the margins get thinner, safety nets are eroded, and QA becomes a fond memory. And "productivity" (lines of code) goes up. The board is ecstatic, and all those troublesome bugs are just a cost of doing business.
After all, you can always improve the code later. Except, wait, there's a brand new function that needs adding, forget dusting for cobwebs (i.e. fixing major flaws) in the old code!
Cynical? Of course. True? Usually. 🙂
DevOps is a good idea, but not for all the usual suspect reasons. Certainly it allows creation of a process that is repeatable. Certainly allowing the computer to perform the steps insures consistency, and can even prevent errors.
What it should not be used for is increasing development speed. Or replacing dedicated QA human resources. Automated tests are a good thing, I love them--but they come at a cost. They catch the easy stuff, true. But in today's complex world the easy stuff isn't the problem. The problems come when you hop up and down on alternate Thursdays and type slowly (but only at 3:15 PM) instead of quickly while not reciting Murphy's Prayer in the key of C.
In other words, nearly unreproducible errors that can only be caught by people who know how to reproduce the irreproducible so developers can actually fix it.
Oh, and this can take days for even one bug (as management has a collective coronary).
DevOps? Yes, please. But give me a heaping helping of QA resources to go with it!