I don’t know about everyone else, but I design tests to
- Verify that things work as I expect them to
- Verify that the system handles unexpected things with a degree of grace
- Verify that users aren’t going to be asked to do something really confusing/weird/counter-intuitive
- See if I can break the system in a way that exposes security flaws.
- See if I can break the system in a way that a user is likely to act.
- Verify that other important features are still working as designed.
That’s not a complete list, but it covers most of what I do - and only the last item would count as “slow, boring, and error-prone” when done manually. For a new development, exploring the changes may be slow, but it’s certainly not boring, and the error-proneness usually has more to do with factors that have nothing to do with me.
I got to that point of the blog, and immediately dismissed the article as “let’s sell the rubes a tool that might or might not do what they need”.