eigentlich will er ja wohl den klassischen v-modell / wasserfall ansatz mit agilen methoden aus testsicht verglichen..

aus der agilen sicht, gehört testen während der entwicklung einfach dazu. eine der base practices von extreme programing ist TDD (test driven development), wobei hier natürlich unit-tests gemeint sind.

und es ist meiner meinung nach ganz egal wie groß das teil ist, ne handvoll unit-tests sind sofort mitgeschrieben, und ich kann nach jedem build prüfen ob ich was kaputt gemacht habe.

wie yogi schon konkret angemerkt hat, steigt der aufwand einen fehler zu beheben je später man ihn findet. der worst case ist hierbei bei einem kommerziellen projekt der rückruf wenn die software schon produktiv im Einsatz ist.

wenn man das ganze mal schwarz/weiss malt:

testen nach der entwicklung:
typisches problem: man denkt, die software ist ja eigentlich fertig und dann dauert die Fehlerbehebung die in der nachgelagerten Testdurchführung gefunden wird genauso lange wie die Entwicklung bisher.
Der Testumfang ist natürlich auch riesig; dauert also entsprechend, und ich bekomme das Ergebnis erst viel später. Das kann durchaus mehrere Wochen in Anspruch nehmen.
Dann wird Fehlerbehebung betrieben, dann wieder getestet und das ganze dauert wieder ... usw usf .. das macht aus heutiger sicht einfach keinen Sinn.

testen während der Entwicklung.
okay malen wir hier mal die schöne heile welt:
es gibt unit-tests die schonmal einiges finden, parallel zur entwicklung werden systemtests gemacht, die tester sind optimal ins team integriert, wissn also bescheid welche funktionen bereits implementier sind und welche nicht.
Die direkte kommunikation erlaubt es Fehler meist direkt mit dem Entwickler zu klären, und die bugs werden auch direkt gefixt. am Ende einer iteration wird ein abschliessender Test durchgeführt, der nur noch sehr wenige fehler finden sollte.
diese werden dann in der nächsten iteration mit behoben.
prima..
der testaufwand am ende einer iteration wäcst hier kontinuierlich an.. sodass diese aktivät wenns dumm läuft länger dauert, als eine iteration.
was nun --> zauberwort testautomatisierung so hoch wie möglich
nachteil, das kostet geld und zeit.
aber man bekommt sehr schnell ergebnisse, die tester haben zeit für exploaritve tests.
die software wird so deutlich schneller eine reife erreichen als mit dem klassischen Ansatz!
am ende macht man eine test und bugfix iteration, die ausgelegt ist nur noch fehler zu eliminieren und keine neuen funktionen mehr zu integrieren.

zieht man das so durch, ist man auf nem sehr guten weg.

das mal in aller kürze