1. /Inside
  2. /Fail fast – succeed faster

Testing trägt einen großen Anteil zur Entwicklung und zur Qualität eines Produktes bei. Diese Aussage ist heutzutage unumstritten, losgelöst davon, in welchem Bereich und nach welchem Modell entwickelt wird.

Unabhängiges Testen frühzeitig in den Entwicklungsprozess zu integrieren, fällt jedoch vielen Unternehmen immer noch schwer, insbesondere auf Integrationsebene. Dabei begegnet man folgenden Aussagen immer wieder:

  • Wir testen doch permanent. Das erledigen unsere Entwickler gleich mit.
  • Ständiges Testen ist zu teuer, das machen wir am Ende einmal gründlich.
  • Wir würden gerne testen, aber die Komponenten XYZ sind einfach noch nicht so weit.

Höchste Zeit, sich mit diesen „Argumenten“ einmal im Detail auseinanderzusetzen.

Wir testen doch permanent ...

Entwickler sollen selbst testen – das ist richtig und wichtig. Allerdings fehlt einem Entwickler häufig der nötige Abstand zu seinem Code. Er ist sozusagen betriebsblind. War beispielsweise eine Anforderung unklar formuliert, lag eine veraltete Spezifikation vor oder wurde etwas nicht richtig verstanden, so wird der Test dies nicht aufdecken können, wenn er vom selben Entwickler durchgeführt wird. Der Entwickler kann zwar sehr gut testen, ob sein Code das tut, was er von ihm erwartet, aber seine Erwartungshaltung kann unvollständig oder nicht richtig sein

Testen Entwickler ihren Code gegenseitig, ist dieser Effekt zwar abgeschwächt, dafür minimiert dieser personelle Mehraufwand das meist ohnehin knappe Entwicklungsbudget. Davon abgesehen, ist es fragwürdig, ob der zweite Entwickler im Besitz eines aktuelleren Anforderungsdokuments ist. Zudem liegt den Entwicklern in aller Regel nur die Spezifikation für ihre Komponenten vor – auf die übrigen Spezifikationen haben sie oftmals keinen Zugriff. Das Ergebnis ist, dass sie spätestens auf Integrationsebene nicht mehr selbst testen können.

Ständiges Testen ist zu teuer ...

Mittlerweile ist der Umstand, dass die späte Durchführung von Tests im Entwicklungsprozesses keine finanzielle Einsparung mit sich bringt, Gegenstand vielfacher Untersuchungen (z.B. ingenieur.de und xbsoftware.com). Ganz im Gegenteil. Wer früh ins Testen investiert, kann auf Dauer sehr viel Geld sparen. Generell gilt: Je früher ein Fehler im System entdeckt wird, desto kostengünstiger kann er behoben werden. Der Fehler, der nie im Code landet, ist verständlicherweise am günstigsten. Vermeidbare Fehler entstehen durch unvollständige, inkonsistente oder nicht eindeutig formulierte Anforderungen. Ein kurzer Vergleich offenbart hier schon das große Einsparpotenzial:

Auf der einen Seite haben wir ein bis zwei Reviewer, die die Anforderungen durcharbeiten, Unklarheiten und Probleme markieren und gemeinsam mit dem Autor des Dokuments eine überarbeitete Version erstellen. Diese wird an die Entwickler übermittelt.

Auf der anderen Seite haben wir einen Tester, der einen Fehler findet, ihn meldet und mit seinem Testmanager bespricht. Der Fehler wird an den Entwickler 1 übermittelt, der feststellt, dass das Problem gar nicht mit seiner Komponente zusammenhängt. Er gibt ihn an Entwickler 2 weiter, der für eine andere Komponente zuständig ist. Entwickler 2 findet den Fehler zunächst nicht, bis er – nach Konsultation mit dem Entwickler 1 – auf die Idee kommt, dass beide Komponenten im Sinne der Spezifikation richtig umgesetzt worden sind, jedoch die Spezifikation nicht zusammenpasst.

Anschließend wird die Spezifikation überarbeitet, mindestens eine der beiden Komponenten geändert (mit den zugehörigen Komponententests) und anschließend wieder dem Tester zum Retest übergegeben. Dabei wurde das Regressionsrisiko noch nicht betrachtet, ebenso wenig der Stimmungsabfall im Entwicklungsteam. Natürlich sind nicht alle Fehler vermeidbar und auch im Review werden nicht alle Probleme identifiziert, dennoch bieten Reviews dank geringer Kosten ein hohes Potenzial zur Kosteneinsparung und zur Verbesserung des Arbeitsklimas.

Sofern ein Fehler seinen Weg in den Code gefunden hat, ist es selbstverständlich sehr lohnenswert ihn möglichst zeitnah zu finden. Ein Entwickler kann seinen Code schneller ändern, wenn er sich noch tief im aktuellen Entwicklunggeschehen involviert ist. Es ist menschlich, dass wir uns besser an das erinnern, was wir gestern oder vorgestern gemacht haben, als an etwas, was wir vor zwei Monaten entwickelt haben. Zudem ist in aller Regel das Regressionsrisiko niedriger, da es weniger Code gibt, der mit dem gefundenen Fehler in Verbindung steht, allein aufgrund der Tatsache, dass insgesamt weniger Code vorliegt. Wie im Fall von vermeidbaren Fehlern, kann auch hier die Blockierung von Mitarbeitern durch frühzeitiges Fehlererkennung vermieden werden.

Wir würden gerne testen, aber ...

Es kommt in Projekten immer wieder vor, dass der Integrationstest erst spät beginnt, weil die Entwicklung einer Komponente hinterherhinkt, losgelöst davon, ob die Software noch nicht einsatzbereit oder eine Platine noch nicht verfügbar ist.

In diesem Fall lohnt es sich, darüber nachzudenken, ob die Komponente oder genauer gesagt – ihre Schnittstelle – auf Systemebene simuliert werden kann. Kann auf diese Weise ein lauffähiges System hergestellt werden, können zumindest die Schnittstellen zwischen den übrigen Komponenten betrachtet werden. Können sogar Daten oder Nachrichten dieser Komponente simuliert werden (Nachrichten auf ein BUS-System schreiben, Einträge in eine Datenbank injizieren etc.), kann ebenfalls die Schnittstelle zu der fehlenden Komponente zumindest einseitig auf der Seite der bereits vorhandenen Komponenten getestet werden. Sind also fünf von sechs Komponenten einsatzbereit, so können im Idealfall bereits auch 5/6 des Integrationstests bereits durchgeführt werden – als sogenannter Pre-Integrationstest.

Fazit.

Es lohnt sich außerordentlich, in die frühzeitige Fehlererkennung zu investieren – sowohl durch Reviews, als auch durch unabhängiges Testen in der frühen Entwicklungsphase. Die Pluspunkte sprechen für sich: Es kostet wenig, kann zur gänzlichen Fehlervermeidung beitragen, ermöglicht eine effizientere Fehlerkorrektur, verringert das Regressionsrisiko und reduziert drastisch das Risiko eines Entwicklungsstillstandes durch Blocker-Themen.

Zudem hat es noch einen weiteren Vorteil: Fragen Sie doch einmal den Tester oder den Testmanager eines früh in die Wege geleiteten Tests nach dem aktuellen Projektstand. Er wird Ihnen Auskunft über alle Komponenten geben können. Und dies in einer neutralen Form und ohne, dass Sie sich die Informationen mühsam von den Teilprojektleitern zusammensuchen müssen.

Sie haben weiterführende Fragen zum Thema Testing, Testingmanagement und (Pre)Integrationstesting? Wir freuen uns über Ihr Anliegen.

Dr. Juliane Hansmann
Juliane Hansmann gehört zum UXMA Data Science Team. Mit ihrer Erfahrung aus der Mathematik und Datenverarbeitung ist sie Expertin für (Pre-)Integration Testing.
props.nextPost.title

Die Wahrheit liegt im Code.