Quality Engineering often gets blamed when pipelines are slow or E2E tests are flaky. It’s an easy target. A red pipeline is visible, the real cause often isn’t.
What’s usually ignored is this:
test automation is hard and expensive to maintain.
ISTQB is very clear on this. Automation is not a one-time setup. It requires continuous maintenance due to system changes, environment instability, and data dependencies. When the system is unstable, tests simply expose it.
E2E tests don’t create problems. They surface them.
Most failures fall into a few boring but important categories.
App Behaviour Issues
“E2E failed due to unexpected application behavior. We’ll clarify with the product team whether this is a defect or a temporary issue.”
Translation: the app didn’t behave as expected. That’s not a test bug.
Environment Slowness
“E2E failed due to environment slowness. We’ll review test optimizations on our side, but the root cause is not fully test-related.”
Translation: shared env, slow backend, overloaded services. Tests just happen to run there.
Unknown or Infra Issues
“E2E failed due to an infrastructure or DB issue. Root cause is unclear for now, we’re investigating.”
Translation: infra is flaky. QE didn’t deploy the database.
When Other Teams Complain
“The tests surfaced an issue in the system. We’re checking whether it’s functional, environmental, or temporary.”
Translation: don’t shoot the messenger.
If you want fast pipelines and stable tests, you need stable systems, realistic expectations, and shared ownership. QE can optimize tests, but QE cannot compensate for broken foundations.
Red pipelines are feedback. Ignoring them doesn’t make delivery faster.