Abstracts

In der Musik gibt es zwei Arten von Instrumentenfamilien. Wer von Sopran- auf Tenorblockflöte wechselt, liest genau die gleichen Noten, muss aber anders greifen, um den Ton zu treffen. Wer vom Alt- zum Tenorsaxophon wechselt, braucht spezifische Noten, muss dafür aber praktisch keine neuen Griffe lernen. Im ersten Fall transponieren wir im Kopf, im zweiten Fall sind die Noten transkribiert.

Warum ich das erzähle? Weil es eine Parallele zum Softwaretest gibt. In der klassischen, V-Modell-basierten Vorgehensweise transkribieren wir die Anforderungen in Testspezifikationen für manuelle Tests, die dann irgendwann in automatisierte Testskripte übersetzt werden (oder auch nicht). Alle Spieler haben ihre eigenen Noten. Das hat den Vorteil, gut dokumentiert und nachvollziehbar zu sein.

Es gibt allerdings auch den anderen, agilen Trend. Wenn wir ohnehin eine vollständige Automatisierung der Tests anstreben, wozu brauchen wir dann noch eine Testspezifikation? Wir können doch die Anforderungen direkt in Testskripte transponieren. Wie die Entwickler zu sagen pflegen: „Ein gut geschriebener Code ist die beste Dokumentation.“ Oder wir stellen die Testspezifikation an den Anfang und sparen Aufwand bei der Verfeinerung der Anforderungen (Stichwort: ATDD / BDD).

Die zweite Variante hat den offensichtlichen Vorteil, die Dokumentationslast zu reduzieren. Nur: Wie nachhaltig – im Sinne von dauerhaft wertvoll – ist sie? Wie schaut es aus, wenn es an die Überarbeitung der Tests geht? Denn es gibt durchaus weitere Argumente, die für den Erhalt der Testspezifikation sprechen. Obendrein haben wir nicht immer die Wahl, wenn z.B. in der Medizintechnik Testspezifikationen explizit durch Regularien gefordert sind. Oder doch? Welche KI-basierten Tools gibt es, die uns einen Teil der Arbeit abnehmen können? Wie passt modellbasiertes Testen (MBT) ins Bild? Solche und ähnliche Fragen werden wir im Rahmen eines World Cafés gemeinsam diskutieren.