http://blogs.msdn.com/micahel/archive/2005/12/14/WhenToAutomate.aspxMy team has a goal of 110% automation, but: not every test is worth automating. What's more, the value in automating a particular test case changes depending where in the product cycle you are. Or as I said in a presentation on this topic: What shoulden-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/micahel/archive/2005/12/14/WhenToAutomate.aspx#512293Fri, 13 Jan 2006 03:26:35 GMT91d46819-8472-40ad-a661-2c78acb4018c:512293patrick taylorI am confused by your third bullet in that unstable/newly developed/high change code should have automated tests written for it. <br> <br>It has been my experience that test automation is a great deal of work to maintain and that the more changes there are to an application under test the more automation maintenance work is required. It almost never pays off to write automation against an application that is undergoing major changes to its UI, structure, or functionality. Having to rewrite large portions of the automation code and cases on every build often takes longer than it would take to perform those tests manually. Additionally it is of paramount importance that a human being’s intuition is leveraged on very new code to account for that which had not yet been considered. I have had very good luck using automation for regression testing or getting lots of boundary cases executed, but only on code that was pretty well established. <br> <br>Am I missing something? <br>http://blogs.msdn.com/micahel/archive/2005/12/14/WhenToAutomate.aspx#521179Wed, 01 Feb 2006 01:54:14 GMT91d46819-8472-40ad-a661-2c78acb4018c:521179Harry Nieboerhttp://blogs.msdn.com/micahel/archive/2005/12/14/WhenToAutomate.aspx#542689Fri, 03 Mar 2006 07:29:07 GMT91d46819-8472-40ad-a661-2c78acb4018c:542689The Braidy TesterPatrick comments on my When To Automate post: <br>I am confused by your third bullet in that unstable/newly...