Ein Ent­wick­ler tes­tet oft nur den “Hap­py Path” – also ob sei­ne Funk­ti­on unter Ide­al­be­din­gun­gen funk­tio­niert. Er ist natur­ge­mäß betriebs­blind für sei­ne eige­ne Arbeit. Ein agi­ler Tes­ter hat eine ande­re “Bril­le”: Er denkt destruk­tiv, tes­tet Rand­fäl­le, sucht nach uner­war­te­ten Sei­ten­ef­fek­ten und hin­ter­fragt die Logik aus der Per­spek­ti­ve des Nut­zers. Bei­de Rol­len sind für eine hohe Qua­li­tät uner­läss­lich.

Das bedeu­tet, dass wir ein Pro­gramm schrei­ben, das Ihre Soft­ware tes­tet. Anstatt dass ein Mensch sich bei jedem Sprint manu­ell durch die 20 Kern­funk­tio­nen kli­cken muss, um zu sehen, ob noch alles geht (Regres­si­ons­test), erle­digt das ein auto­ma­ti­sier­tes Skript in weni­gen Minu­ten. Das gibt dem Team nach jeder Ände­rung sofort die Sicher­heit, dass die Basis­funk­tio­na­li­tät noch intakt ist.

Ja, wenn er als Coach agiert. Sei­ne Auf­ga­be ist es nicht, alles selbst zu tes­ten. Sei­ne Auf­ga­be ist es, einen effi­zi­en­ten Pro­zess zu eta­blie­ren. Er baut die Test­au­to­ma­ti­sie­rung auf, die einen Groß­teil der Rou­ti­ne­ar­beit abnimmt, und befä­higt die Ent­wick­ler, bes­se­re Unit-Tests zu schrei­ben. Er selbst kon­zen­triert sich dann auf die kom­ple­xen und krea­ti­ven explo­ra­ti­ven Tests.