Why Fake Automated Testers and Software Test Architects Love ‘Headless Browser Testing’?

To hide their incompetence in E2E Test Automation.

In previous articles (#1, #2), I mentioned the embarrassing history of ‘Headless Browser Testing”:

• PhantomJS (2010–2015)
  Deprecated in 2017.

• Google Chrome headless is a separate implementation, before v112
  Real software testers know what it means.

Despite that, the love of “Headless Browser Testing” did not fade. The default running mode in so-called modern Cypress and Playwright is headless. Why is that? In this article, let’s dive into this matter, trying to explain the human factors behind that. (I will soon write another article from a technical aspect. There is only a tiny neglectable speed benefit for headless, but with big issues and missing many good benefits of running visible E2E UI tests).

Table of Contents:
· Most software engineers do not have E2E Test Automation knowledge
· Senior ‘Engineers’ naturally prefer concealing their lack of comprehension in E2E Test Automation.
· What If we run E2E (via UI) tests in normal mode, frequently?

Most software engineers do not have E2E Test Automation knowledge

This is a fact and not their fault. A graduate with a degree in computer science spends three or four years in university, focusing predominantly on programming. Surprisingly, no specific courses were dedicated to E2E test automation and Continuous Testing, areas considered more challenging by industry professionals.

“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
- Patrick Copeland, Google Senior Engineering Director, in an interview (2010)

95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”.
- this interview from Microsoft Test Guru Alan Page (2015), author of “How we test software at Microsoft”

“Testing is harder than developing. If you want to have good testing you need to put your best people in testing.”
- Gerald Weinberg, software legend, in a podcast (2018)

If E2E test automation is implemented well, its benefits far exceed just QA.

• Benefits of Real Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers

In a real Agile team, all members will get involved with E2E (via UI) Test Automation, daily. Based on my observation, ~70% of SDLC Effort is on Software Testing and Related Activities.

To really master E2E test automation, it almost certainly needs to engage a Test Automation coach. The reasons are simple:

• You don’t learn it at universities

• Most (99.9+%) software professionals have never witnessed (let alone participated in) a real Agile project with Real E2E (via UI) Test Automation.

Would your software architect or principal software engineer seek mentoring in test automation? It is very unlikely, only extremely wise ones do that.