In an article about the unreliability of embedded software, for some reason someone decided to add some comments about what they think you should do when improving software. http://www.baselinemag.com/article2/0,1540,1150971,00.asp however they claim they got it from ABN Amro Services Co.

Their points are:

	1. Plan ahead - Think through your testing process.  Test code's behavior under both expected and unexpected conditions.
	1. Test early - The earlier the better.  Appeal to engineers who enjoy breaking things.  
	1. Test manually; Then, automatically  Before code settles down, test manually.  Later, have engineers use automated tests, before turning code in.
	1. Don't test all code at once - Clean up old code as each file gets run.  Fifty percent to 80% of your files should never have to be touched.
Source: ABN Amro Services Co.

What do people think about this advice? 

----
The first two are established. A LittleDesignUpFront is always good, and bugs found early tend to be less bothersome.
Xp advocates writing a test for any bug that is solved, probably not truly "all of them, individually", it's a matter of balance. Also, do it iteratively. Sounds good. . . but is this really "Improving Software"? This sounds rather testing specific. Improving could involve decoupling, formatting, removing redundancies, etc. . . It also sounds a lot like ContinuousTesting, and it could benefit from using TacticalTesting.

The first item should really be split into two items,

	* Define the desired result for both valid and invalid inputs
	* Determine how the test will set up the desired input condition and receive the result.

The first item describes what the program should do.  The second describes how the test is done.