The automation part of the Wikipedia article is there to suggest that in order to be able to do rapid development and deployment (which is really an agile concept, not necessarily a DevOps one), it is necessary to be able to do rapid and consistent regression and functional testing and deployment with minimal effort.
Unfortunately, automated regression and acceptance testing is good at finding the problems you've seen before. It's not so good at finding new problems. That requires time and rigor in the testing processes.
So, by reducing the testing effort to enable rapid deployment of new code, you're actually exposing yourself to unexpected problems closer to the live environment. To my mind, this is the single biggest issue with agile development, and by extension DevOps. IMHO, large organizations that have a critical reliance on their IT systems will remain with their traditional testing regimes, which will make DevOps difficult to integrate into their working practices. It's a Risk thing.
It's interesting that in several organizations I've worked at over the 35+ years I've been working in IT, Operations team members have been present during all phases of projects, and on the distribution and approval lists of the change processes, so communication isn't a new thing. It just seems to have dropped out of favor a bit in recent decades as IT has become more silo'd.