Softwaretest „Legacy-Code ist eine tickende Zeitbombe“

Redakteur: Franz Graser

John Paliotta, Cheftechnologe des Testspezialisten Vector Software, sprach mit ELEKTRONIKPRAXIS über Strategien für bessere Codequalität – und die Gefahren, die in altem Code stecken.

Anbieter zum Thema

John Paliotta: Der Mitbegründer und CTO von Vector Software sieht in der unzureichenden Kommunikation zwischen Entwicklung und Test eines der größten Probleme.
John Paliotta: Der Mitbegründer und CTO von Vector Software sieht in der unzureichenden Kommunikation zwischen Entwicklung und Test eines der größten Probleme.
(Bild: Vector Software)

Viele Experten sprechen ja über eine Verifikationsstrategie mit Test, statischer Analyse, Codeanalyse und ähnlichen Domänen. Wo sehen Sie Ihre Spezialität?

Korrektheit. Statische Analyse ist großartig, wenn es darum geht, Muster von Programmierfehlern zu finden. Aber Sie können in statischer Hinsicht völlig sauber sein und trotzdem eine komplett falsche Applikation haben. Uns geht es in allererster Hinsicht um Korrektheit – um den Beweis, dass der Code das tut, was er tun soll, und nicht darum zu beweisen, dass der Code tut, was er tut! Es klingt zwar ganz ähnlich, aber dazwischen liegen Welten.

Es kommt viel zu oft vor, dass sich die Leute beim Testen auf die vorgegebenen Pfade beschränken. Um gerade diesen Fehler zu vermeiden, brauchen die Leute einen Überblick darüber, was ihre Testfälle tatsächlich prüfen.

Es kann also sein, dass Sie eine sehr robuste Testumgebung schreiben und nur ganz oberflächlich testen. Und ohne Koordination zwischen den Teams, die für den Entwurf, die Entwicklung und das Testen zuständig sind, verlieren Sie eine ganze Menge unglaublich wichtiger Informationen. Die Menschen, die für den Entwurf zuständig sind, wissen eine ganze Menge darüber, was die Applikation tun soll.

Die Person, die den Code schreibt, trifft jeden Tag wichtige Entscheidungen. Wenn ich Code schreibe, dann habe ich immer einen Notizblock neben der Tastatur liegen. Jedes Mal wenn ich eine Bedingung einbaue, notiere ich mir das. Und so habe ich am Ende eine Liste der Grenzfälle, die in dem Code drinstecken, den ich gerade geschrieben habe.

Und ich stelle sicher, dass ich dafür Testfälle schreibe. Und das gebe ich dann den Leuten von der Qualitätssicherung. Die lesen, was der Designer geschrieben hat und interpretieren es. Ich lese als Entwickler, was der Designer geschrieben hat und interpretiere es meinerseits. Aber wir alle arbeiten getrennt voneinander. Wir müssen alle von ersten Tag an zusammenarbeiten und uns darüber einig sein, was die Erfolgskriterien sind.

Artikelfiles und Artikellinks

(ID:44602436)