This is common sense, but I never realized how important this could be to some folks...just knowing that the automation suite has run and all 'those things' are tested is reassuring to folks in a big way. Even if no bugs are found and the time/money is real measurable ROI....just the reassurance can be enough. Even if there hasn't been code changes related to 'those things', it's just nice to know. Especially for management.

I'd rather find bugs and reduce the support calls of course. I guess when a small company like ours has never done any automated testing and you show them that you can go through 1000s of menus and screens in just minutes, it's an eye opener. Especially with a $200 test tool (thanks Joe and WinTask).

It kinda falls into one of the three primary goals mentioned in that excellent "SQA Automation Considerations" whitepaper:

Increasing the accuracy and reliability of quality assessment in a release cycle.

I wonder how much testing, manual and automated, is eliminated when you only test things that are affected by updates to the code. I've worked places where they "connected" millions of functions and objects through the build script so they knew what source code changes would affect what apps, and then only tested the necessary parts, but I bet that's a rare situation. Anyone ever had the case where the "architect(s)" look over all the changes and determine what tests to run? Just ramblin while the search engine timer ticks so I can search again [img]/images/graemlins/wink.gif[/img]