Iterative development of software is a continous process of discovery, invention and implementation. The centrepiece of iterative development is to mitigate risk of failure over the course of a project.

By starting with a narrow focus, the project team can concentrate on the risks that will potentially cause the most problems.

One of the founding fathers of iterative development, Tom Gilb says "If you do not actively attack risks, they will actively attack you." Principles of Software Engineering Management. Addison-Wesley, 1988.

Iterative development was born as a reaction against the Waterfall method of development. The waterfall consists of monolithic stages, which had to occur before the next one could start. The essential premise of the Waterfall is that everything that has gone before including assumptions and decisions have been correct. Unfortunately this rarely is the case. The tendency is therefore to bottle all the bad things up until the end of the project. Thus the risk of failure is maintained at a high level throughout the project. Thus for example, a customer may only see a working demo of the product after a year of development. At which point he says "This is not we wanted".

Organisations develop iteratively for a number of reasons. For example:-

  - misunderstandings are exposed at the start of the project.
  - Feedback from stakeholders can be much more immediate.
  - Critical issues regarding the project are highlighted earlier.
  - Gaps and inconsistencies in requirements and designs are spotted earlier.
  - Assessment of the quality of the application being built can be continually assessed as it grows.

Of course these are all lofty ideals. Once you hear them, self-evidently true. However like all new things magic, they can go wrong. For instance it takes no account of incompetence or politics.

Testing in the RUP is a discipline in itself. It is quite unique in looking for the negative rather than the positive. Two questions need to be answered, is the software good enough and how do I tell everyone. Further discussion of the test discipline is available.

Testing in an iterative environment differs from that of the Waterfall in one important aspect, testing is almost contigous with all the other development activities. Simply this means grow the system a little, integrate, test, assess, amend and grow a little more. This contradicts the classic Waterfall cycle of build the entire system and then start testing.

Due to the proximity of the test efffort with that of analysis and coding, communication between testers, developers and analysts is improved. The test effort will feed back information about the state of the application quicker. Developers are then much better to tie defects to a particular recent effort . In contrast in the Waterfall, months may pass between the code being written and a defect being noticed. The situation is even worse with inconsistencies in analysis or design where the gap may be over a year.

The test process can have a low level of ceremony relative to other projects. Thus when the project is in its early stages, the documentation that will be produced of a broad brush stroke nature or "granularity". As the application grows the supporting documentation grows and at the same time granularity becomes finer. Of course if the project is cancelled, huge amounts of effort has not be been wasted producing mountains of redundant test plans.

Indeed the RUP actually eschews the idea of paper at all. Seeking rather to hold information electronically in a database, so that links and traceability are enable using tools.

The test suite of use cases, grows with the application. Thus it is mirrors the documentation, in that the first tests are of a broad granularity. As the project moves forward granularity becomes finer. This then feeds back into risk mitigation, where the risks left to be mitigated are smaller and smaller.

Regression testing is inherently built into the process. This is due to new functionality being built on the firm foundations of previous iterations. The test case suite continually growing as the project progresses means that every aspect of the software built so far is tested and re-tested.

As the project progresses, the continous assessment of the quality means that the team is aware of the level of quality in the software. Thus confidence should build as with each build or iteration, the risk of failure recedes.

Lastly the iterative testing environment is very conducive to automated testing. As the test suite grows, the repetitive execution can be very tedious leading to errors. As a consequence automated test tools can be used to design, hold and execute the test suite.