Yes, bugs still need to be reported, and not all of them yield to automated tests. Nevertheless I do concur with the spirit of the article. I write very demanding test cases, often before anything goes wrong but certainly after it does, even for non-deterministic code (e.g. I'll fork a thousand processes in an automated test and invoke random busy loops here and there to encourage contention.)
I don't do a lot of GUI though, other than HTML interfaces, which are fairly amenable to some automated testing. One time I broke a sign-up form due to a misnamed field, so now I have an automated test for that.
For things like "Capitalization inconsistent in top nav", that's a prime example of why you still need to keep track of bugs. Even if you're working alone, just keep a "TODO" list. You can keep the TODOs in a note-taking program such as Tomboy, but better yet, put them right in the code. Then don't release until "grep -r TODO" comes up clean. (If you want to postpone a TODO change it to LATER.)
It might be difficult to create a regression test for that one, and it probably wouldn't be cost effective, but I suppose could have a snippet of code that iterated over the list of navigation items and tested the case. Again, probably not worth it. Better just to stomp that TODO and move on.
I can't say I have the silver bullet for the examples you list, but the important thing is to keep manufacturing better bullets with higher silver content. I figure I gotta try at least.
I don't do a lot of GUI though, other than HTML interfaces, which are fairly amenable to some automated testing. One time I broke a sign-up form due to a misnamed field, so now I have an automated test for that.
For things like "Capitalization inconsistent in top nav", that's a prime example of why you still need to keep track of bugs. Even if you're working alone, just keep a "TODO" list. You can keep the TODOs in a note-taking program such as Tomboy, but better yet, put them right in the code. Then don't release until "grep -r TODO" comes up clean. (If you want to postpone a TODO change it to LATER.)
It might be difficult to create a regression test for that one, and it probably wouldn't be cost effective, but I suppose could have a snippet of code that iterated over the list of navigation items and tested the case. Again, probably not worth it. Better just to stomp that TODO and move on.
I can't say I have the silver bullet for the examples you list, but the important thing is to keep manufacturing better bullets with higher silver content. I figure I gotta try at least.