We've seen this before. At first, the E2E tests automate a bunch of tedious manual tests. Then they become the team's "automated test suite." Then nobody (excep

We've seen this before. At first, the E2E tests automate a bunch of tedious manual tests. Then they become the team's "automated test suite." Then nobody (except true believers) tests their code anymore, because "our automated test suite" will surely catch any problems. Then everything starts breaking down the way the author cites. The E2E test suite needs to be thought of differently from a "test suite." It's the last safety net to disprove that the build is worth [manual testing | dogfooding | beta release | prod release]. Any bug found there should be worth a postmortem -- even one as short as "oops, new guy forgot to update the unit tests! fixed, won't happen again!" Of course, bugs will get through to the safety net, even in a system that's working well. But they should always trigger the question whether and how the bug could have been caught earlier.