I know what are you thinking, "why can anyone say that we don't need test automation?" and you're right! But, we need to also consider the context,...
For further actions, you may consider blocking this person and/or reporting abuse
If your automated tests only cover the "happy path", then they're not very good tests.
I agree that you can't rely solely on automated tests. And it seems you understand that the purpose of automated testing is to free up QA resources to work on more advanced testing scenarios. However, automated testing of certain types of code makes more sense because it is tedious and prone to human error. Once you have validated a spec for an automated test, it will run exactly the same way every single time. I've yet to meet a QA engineer who's a robot :)
As you say, unit tests are prime example of what is to be automated. But how far can it go? I'd argue that it should go as far as it possibly can. It's possible to validate all the invariants within the code automatically, and you should. This is perhaps the biggest source of bugs that I can think of: an object in an invalid state that gets persisted, and so on down the line.
I'd also argue for automated tests as much as possible because then developers submit better code. Just as even the most methodical QA engineers may miss something, so much more so do developers. How much time is wasted in QA because you have to send something back nearly right away? How many times does this repeat? If developers are forced to write good tests (or better yet, someone writes good tests for them), then they will submit better work, and QA time is better spent.
Well-written applications should have very little application logic in the presentation layer. And using modern architectures like the so-called "Onion" architecture, you can end up with a highly testable, rich domain model that encapsulates the majority of the business logic. Testing this is both fast and easy. So, put as much in your core classes as you can without taking on dependencies, and write automated tests for full code coverage of this model. Now your manual QA focus can be on the actual application itself, and not the irritating little bugs that affect so many things.
Hello Brian! Yeah you’re right, this post is oriented to e2e automated testing that they’re really expensive to maintain and develop, I totally agree with you, the automation for unit and integration tests should be in a high percentage on each project of course depending on the team QA approach, I really appreciate your comments and clarification!