(Disclaimer: I work for shipyard.build so i am biased here..)
Dev-owned testing (or even dev-involved testing) is much more realistic when devs have shorter feedback loops between their code and its deployment. So often i've seen momentum get lost when devs have a wait period before they can run tests/do basic manual testing. Then the test aspect becomes the thing that "slows down" devs before they ship a feature, so they might tend towards shortcuts
Dev-led testing is too fundamentally different from a QA function, just as any amount of E2E tests can't replace manual testing. Each tries to solve for a different type of problem. Is it possible to do effective dev peer "QA" without essentially duplicating the QA role? And forget about testing one's own work..
DORA, recently, has been moving towards its own sphere outside of DevOps, hence why the acronym isn't usually expanded. So many of the core principles of DevOps (communication, collaboration, working across teams, etc) have impact beyond the DevOps discipline. DORA has been venturing into platform, DevEx, AI, etc.
From last year's DORA report:
"We are committed to the fundamental principles that have always been a part of the DevOps movement: culture, collaboration, automation, learning, and using technology to achieve business goals. Our community and research benefit from the perspectives of diverse roles, including people who might not associate with the "DevOps" label. You should expect to see the term "DevOps" moving out of the spotlight."
> Because ephemeral environments are reproducible on demand (via Docker images, Kubernetes pods, or a cloud VM), you can guarantee that each bisect step sees the same conditions. This drastically reduces "works on my machine" fiascos.
Agree on this pattern for all code changes. Hard to understate the amount of time we've saved by testing against the full prod-like environment right away. An ephemeral env implementation makes this easy and low stakes, so diving right into E2E testing a copy of your real infra isn't wildly unreasonable. However, I work for Shipyard (https://shipyard.build) so I'm a bit biased on these processes.
Dev-owned testing (or even dev-involved testing) is much more realistic when devs have shorter feedback loops between their code and its deployment. So often i've seen momentum get lost when devs have a wait period before they can run tests/do basic manual testing. Then the test aspect becomes the thing that "slows down" devs before they ship a feature, so they might tend towards shortcuts