„Spezifikation” – das klang souverän, und bei einem so komplexen Gebiet wie der Softwareentwicklung war ich sicher, dass es auch eine äußerst komplexe Bedeutung haben musste. Ich stellte mir ein kryptisches Dokument vor, für das man erst einmal drei Jahre Fachchinesisch lernen musste, um es zu verstehen. Lag ich mit dieser Vorstellung richtig? Nicht wirklich, aber ich lag auch nicht komplett falsch.
Werde jetzt in 6-12 Monaten Software-Tester!
Was bedeuten Spezifikationen fürs Softwaretesten?
Was also sind Spezifikationen? Vereinfacht gesagt, handelt es sich hierbei um die Anforderungen an eine Software. Die Spezifikationen teilen uns als Tester mit, was das Programm können soll. Dadurch wissen wir wiederum, was wir testen müssen. Sie helfen uns, mehr über das Programm zu lernen, können uns zu Testideen inspirieren und uns eventuell bereits auf Probleme aufmerksam machen, noch bevor diese tatsächlich in der Software auftreten. Vor allem aber helfen uns Spezifikationen dabei zu beurteilen, ob das beobachtete Verhalten eines Programms gewollt ist oder ob es sich dabei um eine Fehlerwirkung handelt.
Das Verzwickte an Spezifikationen ist, dass sie nicht in Stein gemeißelt sind. Mit der fortschreitenden Entwicklung des Programms können sich auch die Anforderungen ändern: Vielleicht hat sich die Lage auf dem Markt verändert oder irgendjemand hatte einfach eine gute Idee. Auf jeden Fall kann es vorkommen, dass das Programm plötzlich etwas können soll, was ursprünglich nicht vorgesehen war. Wir als Tester müssen daher sichergehen, stets die aktuelle Version der Spezifikationen zur Hand zu haben, sonst entsteht Verwirrung.
Eine Spezifikation deckt selten das gesamte Produkt ab, sondern meist nur Teile. Die können wiederum auch in mehr als nur einer Spezifikation erwähnt werden und manche Teile tauchen sogar in gar keiner Spezifikation auf. Es ist also ein gewisser Rechercheaufwand vonnöten, um einen Gesamtüberblick über alle Anforderungen zu erhalten, die an die Software gestellt werden. Haben wir das aber geschafft, haben wir tatsächlich einen Leitfaden zur Hand, was wir beim Programm testen müssen. Wie wir das anstellen, ist uns wiederum freigestellt.
Spezifikationen sind facettenreich
Spezifikationen können in verschiedenen Formen daherkommen, z. B. als Protokoll für das Entwicklerteam oder als Vertrag mit dem Kunden. Es gibt auch sogenannte implizite Spezifikationen. Diese sind eher inoffizieller Natur, beschreiben aber ebenfalls Erwartungen, die an die Software gestellt werden. Vielleicht wurden sie von den Entwicklern in anderen Dokumenten als den Spezifikationen erwähnt oder es handelt sich um Aspekte, die für derartige Programme einfach üblich sind.
Wer würde zum Beispiel eine Social-Media-App nutzen wollen, in der keine Bilder geteilt werden können? Oder eine Shopping-Webseite ohne Warenkorb, in dem man seine Waren sammeln kann, ehe man sie in einer großen Gesamtbestellung kauft? Oder ein Fantasy-Rollenspiel ohne Magie und Fabelwesen? Wir alle hegen gewisse Erwartungen an eine bestimmte Art von Programm und wären sicher sehr enttäuscht, wenn diese nicht erfüllt werden.
Allerdings ist „weil es eben dazu gehört” ein ziemlich schwaches Argument, um die Stakeholder von der Notwendigkeit einer bestimmten Softwarefunktion zu überzeugen. Daher sollten auch implizite Spezifikationen möglichst durch seriöse Quellen belegt werden: Wenn sich ein einzelner Nutzer beschwert, dass ein bestimmtes Feature nicht vorhanden ist, wird das die Stakeholder eher wenig interessieren. Wenn besagtes Feature aber im Vorfeld lauthals von der Marketingabteilung angekündigt wurde oder im Benutzerhandbuch der Software erwähnt wird, sieht das schon anders aus. In diesem Fall wäre es nicht nur sehr blamabel, wenn das versprochene Feature fehlen würde, es könnte auch ernste Konsequenzen nach sich ziehen.
Abweichungen von den Spezifikationen
Was sind das für Konsequenzen? Das hängt letztendlich davon ab, wie stark das Ergebnis von der Spezifikation abweicht und um was für eine Spezifikation es sich dabei überhaupt handelt. Wird dem Kunden zum Beispiel nicht das Produkt geliefert, das ihm laut Vertrag versprochen wurde, kann dies juristische und finanzielle Folgen für die Entwickler haben. Gleiches gilt, wenn es sich bei den Spezifikationen um gesetzliche Vorgaben handelt.
Macht wiederum das Marketing den Nutzern bestimmte Versprechungen, die das tatsächliche Produkt nicht einhält, wird zumindest das Vertrauen in das Produkt stark erschüttert. Dies kann sich negativ auf den Verkauf auswirken und unter Umständen ebenfalls juristische Konsequenzen nach sich ziehen.
Auch für uns als Softwaretester können Unstimmigkeiten mit der Spezifikation zu Problemen führen. Behauptet beispielsweise die Spezifikation, das Programm sei mit einem anderen kompatibel, was aber in Wahrheit nicht der Fall ist, wird unser Kompatibilitätstest vermutlich fehlschlagen.
Fazit
Spezifikationen mögen nicht die Ehrfurcht gebietenden Textungeheuer sein, als die ich sie mir zu Beginn meiner Ausbildung ausgemalt habe. Tatsächlich entpuppten sie sich sogar als sehr nützlich, als ich meine Tests erstmals anhand von Spezifikationen plante und durchführte. In jedem Fall sind sie komplex und bringen ihre ganz eigenen Herausforderungen und Fallstricke mit sich. Sie sind mal mehr oder weniger flexibel, mal mehr oder weniger verbindlich, mal mehr oder weniger ausführlich. Sie zu durchschauen, kann zweifellos frustrierend und zeitraubend sein. Doch am Ende erhalten wir eine wertvolle Übersicht, was von der zu testenden Software erwartet wird und was nicht.
