[NikolaNovak]

Agreed; all large, very traditional, very legacy waterfall projects I participated in had:

* Unit testing immediately upon developing any component.

* System & Integration testing starting at some point during development - overlapping phases

* User/Client Acceptance testing also overlapping with end of development (but with planned fix cycles)

* Performance testing... unfortunately depends heavily on the project and its perceived performance but usually in the latter third. Well managed projects see it as "Performance Testing & Tuning", and plan for several iterative cycles of testing and improving performance. Poorly managed projects see it as "Performance checklist" and have a single cycle with no time for tuning.

This is as old-school methodology as it gets, and yet it's been consistently refined and works well when managed well and in right situation/client. A lot of multi-year back-office ERP or infra work for large corporations or public sector inherently needs to adopt similar approach because it's just the nature of client environment. At highest of high levels it's about 5 gantt chart phases with heavy, heavy overlapping and lots of cycles for fixing/improving.

A two-stage dev + test without even an arrow from test to back... I have no idea how that'd work in either theory or practice. Waterfall doesn't have to ignore realities of the world... it just is suited to different realities than Agile.