Google, some months ago, posted an article on their testing blog that supports the use of the test pyramid for a more reliable automated software testing process. I can’t disagree, as I’ve understood it first-hand that automated user interface end-to-end tests are often flaky, difficult to write, and time-consuming to run. It would probably be better for software teams who rely heavily on such tests to rethink their strategy, to start investing more on having programmers that are on board about writing unit tests to catch major problems in code architecture and major functionality early on the software development process, especially those who implement an agile development setup.
However, I find it difficult to insert unit tests on legacy systems (but not impossible), especially with teams that battle project deadlines one after another, which happen quite often in reality (especially in my country). Right now, my team’s current software testing process is mostly made up of exploratory user acceptance tests and automated end-to-end functional regression tests, which is not that bad.. but it’s definitely obvious that we’re not yet as efficient as we want to be. We’re doing good so far, but clearly we can be better and faster, more trustworthy even when releasing more, something to look forward in the near future. But for now I’ll just focus on what I can do: I can’t write unit tests, but I can listen to what my automated tests tell me, and I can strive for better maintainability, cycle time, and dependability.