Automated test scripts are not necessarily the same as unit tests that can be run automatically.

Unit tests are pieces of code that test (usually small) pieces of main code. The tested small piece of code can be a very simple method or a complex one. The idea is to have code that can be used to test your code. Usually, unit tests don't run complex customer scenarios. But when u have small unit tests that cover most "simple" code and u can run it automatically (where automatically may mean that you trigger it manually :) ), you save tons of developer's test time - because each developer can run a lot of tests very fast to test their current changes. Look at junit for java - it is probably the most known unit test "framework". In my experience, if you have good coverage with unit tests, there's almost no regression.

I hate code reviews based on change impact. First of all, on complex/large projects, it's next to impossible to asses the change impact correctly. Second, most big problems/bugs are introduced by changes that apparenly are local and isolated (in my experience, at least).

Vlad


>We looked at Automated test scripts but it was huge. We have an ERP application and just that task alone would be huge. Some year soon we plan on moving off VFP and at that time of the rewrite we will incorporate automated testing. I think that will be the key to get the system out faster.
>
>We currently code review based on the impact of the change.
>
>Somethings we have done that have been huge helps.
>
>1) Bug bash day. Everyone in the entire company gets to test the system however they want. The person & department with the most reported bugs get prizes. You'll be surprised how competitive people are. We had to get over developer ego's for this to work.
>
>2) Release Candidates - we call them Beta Live customers but releasing to a selective few customer to run their business on your software before releasing to everyone made a big impact.
>
>>Don't expect results over night. :) Usually, the results are obvious after a full release cycle - mostly when you see that there are less bugs and, most importantly, the bugs are less severe. Another advantage I've seen is a lot less overtime. :)
>>
>>In the end, it's all about better quality for less. And, in my opinion there are 3 very important things that get u there (beside agile, scrum, extreme, etc). These 3 can be applied even if nobody mentions agile this or that:
>>- Automated unit tests - the unit tests must be written when the main code is written and have to be run automatically by the build
>>- Code reviews - (almost) no line of code goes in without being reviewed by somebody who can actually understand it :)
>>- Continuos integration - automated build that runs continuosly (and runs the unit tests :) )
>>
>>Another interesting quality improver that I've tried is design and code inspections. Since that has to be followed religiously to get results, it's sometimes very difficult to convince the team to do it.
>>
>>Vlad
>>