Software testen

Es bestehen zahlreiche Möglichkeiten um Software zu testen. Wichtig erscheint mir, dass man sich den Testzielen bewusst ist. Von diesen Zielen abgeleitet, kann ein passendes Set an Tests geplant und durchgeführt werden. Das Vorgehen für Software Tests kann analog dem Anforderungsmanagement gegliedert werden: Testvoraussetzungen und Testfälle ermitteln, dokumentieren, prüfen und abstimmen, durchführen und verwalten. Selbstverständlich ist bei der Wahl des passenden Test-Sets auch der Ressourcen- und der Zeitaufwand ein wichtiges Kriterium.

Das Testen selber kann ebenfalls auf unterschiedliche Arten erfolgen. Beispielweise

• anhand von (allgemeinen) Checklisten;
• entlang der bereits bestehenden Spezifikationen;
• anhand von individuell erstellten Testdrehbüchern;
• angeleitetes Testen;
• selbstständiges "drauflos" Testen;
• automatisierte Tests oder
• delegiertes Testen

Diese und weitere Testarten können in Teilen theoretisch, an einer Testumgebung oder am "Original" angewendet werden. Zum Testen von Software stehen somit zahlreiche Möglichkeiten, Vorgehen und Arten zur Verfügung. Die Situation, die Ziele, der Softwareumfang, die bisherige Zusammenarbeit, die eigenen Erfahrungen, die Ressourcen und weitere Aspekte definieren schlussendlich ein passendes Test-Set.

anhand von (allgemeinen) Checklisten

Je abgestimmter ein Software Test ist, desto qualitativ hochwertigere Resultate dürfen daraus erwartet werden. Sie können einen Rotwein bestellen und bei der Lieferung die Farbe prüfen. Wenn dann Ihre  Prüfung (bspw. Durch einen Augenschein auf die Weinfarbe im Glas) wirklich "rot" ergibt und Sie damit die Bestellung zufrieden abschliessen und die Rechnung bezahlen, dann war dies eine gut passende Checkliste. Bei allgemeinen Checklisten kann wenig auf spezifische Anforderungen eingegangen werden. Der Vorteil liegt in den Aufwendungen für das Testen. Dies ist mit Abstand die einfachste und schnellste Variante. Wenn Sie nun auch noch die Füllmenge, den Jahrgang, das Weingut, die Traubensorte, die Aromatik, den Abgang, … testen wollen, dann führt dies sinngemäss bei Software Test unweigerlich zu weiteren Aufgaben.

Weiterführende Tests und damit verbundene Aufgaben sind, wie angesprochen, mit weiteren Aufwendungen verbunden. Dies kann auf Kundenseite rasch einmal 5 bis 10% (oder auch mehr) der gesamten Aufwendungen eines Softwareprojekts ausmachen. Erwähnenswert ist dabei, dass diese Aufwendungen und Aufgaben den "nicht delegierbaren" Teil, beispielweise an den Software Anbieter oder die Herstellerin, umfassen.

entlang der bereits bestehenden Spezifikationen

Damit ist gemeint, dass mit den Tests bereits vorausgegangene Aktivitäten gegengeprüft werden. Beispielweise wenn eine Spezifikation erstellt wurde, dann kann der aktuelle Stand der Software gegen diese Spezifikation geprüft werden. Früh im Projektverlauf angewendet, profitieren dabei alle Beteiligten von einer frühen Identifikation von Mängeln, Missverständnissen, Redundanzen, fehlenden Funktionen oder weiteren Erkenntnissen. Sie dient auch dem gegenseitigen Verständnis und des Wissensaustausches. So wird quasi das ganze Team involviert, was der gemeinsamen und positiven Lernkurve positiv zuträglich sein wird. Der Nachteil dieses Vorgehens liegt tendenziell dabei, dass ein starker Fokus auf den bisherigen Annahmen liegt und somit weitere Potenziale nicht sichtbar werden. Somit ist dieses Vorgehen sehr geeignet, wenn eine Software bereits in wesentlichen Teilen vor dem Projekt bestand und nun noch die kundenspezifischen Anforderungen getestet werden.

anhand von individuell erstellten Testdrehbüchern

Damit ist gemeint, dass mit Tests die Software entlang tatsächlicher Abläufe der Unternehmung (Prozesse) geprüft wird. Beispielweise kann ein bereichsübergreifender Prozess festgelegt werden und Schritt für Schritt und in Unterstützung der Software geprüft werden. Dabei ergeben sich neben den grundsätzlichen Vorteilen, wie dem sehr realitätsnahen Testen oder dem Zusammenspiel einzelner Funktionen, auch einige positive Nebeneffekte. So kann die Prozesslaufzeit mit der aktuellen Softwareunterstützung gemessen werden, die Performance überprüft und die Zusammenarbeit unterschiedlicher User abgestimmt werden. Der Nachteil dieses Vorgehens liegt tendenziell dabei, dass damit ein noch höherer Aufwand verbunden ist. Auch kann es grössere Abweichungen zu bisherigen Annahmen ergeben. Dies führt nicht selten auch zu Fragen der Organisations- und/oder Prozessanpassung. Ob dies wiederum gewünscht wird ist dem jeweiligen Unternehmen überlassen.

nicht-funktionale Tests

Die nicht-funktionalen Test dienen wohl in erster Linie der Akzeptanz der Software Lösung. Eine einzelne, funktionale Anforderung kann noch so gut getestet und als einwandfrei klassifiziert sein. Wenn diese beispielweise bedienungsunfreundlich, nicht-performant, technologisch veraltet, rechtlich/vertraglich gegenläufig, Datenschutz-verletzend oder unwartbar ist, dann wird die gesamte Software (resp. deren Einsatz) wohl eher als nicht erfolgreich gelten. Bei den nicht-funktionalen Tests werden Qualitätsmerkmale und Rahmenbedingungen getestet. Dazu gehören beispielsweise:

• Technologische Anforderungen wie bspw. Softwareschnittstellen, Vorgaben an Hardwarekomponenten, aber auch Themen welche auf den ersten Blick wenig relevant erscheinen können wie beispielsweise Wetter-/Klima- Bedingungen
• Effizienz, bspw. Antwort- oder Verarbeitungszeit
• Interoperabilität und Ordnungsmässigkeit, bspw. der Schutz von personenbezogenen Daten
• Last und Performance, bspw. in Abhängigkeit der gleichzeitigen Transaktionen oder aktiver User
• Zuverlässigkeit über einen definierten Zeitraum
• Benutzeroberfläche, bspw. Gestaltung, Anordnungen, Schriften, Farben, sichtbare Bedienelemente, Tabellen

Ein weiterer Bestandteil der nicht-funktionalen Test kann von den rechtlich-vertraglichen Anforderungen sowie von den folgenden Lieferobjekten abgeleitet werden:

• Schulungsunterlagen
• Benutzerhandbuch
• Wartungshandbuch
• Hardware- und Softwaredokumentation

Software testen um Mängel und Fehler zu finden

Ja, Testen ist eine Disziplin um Mängel zu identifizieren. Fehlerhaftes Verhalten der Software kann grosse und unangenehme Folgen nach sich ziehen. Da dies weder im Interesse des Kunden, noch des Software Anbieters noch der Software Herstellerin liegt, ist ein konstruktives, gemeinsam abgestimmtes und systematisches Testvorgehen sicherlich eine gute Wahl. Das Testen setzt Testziele voraus, daraus das passende Test-Set definiert und dokumentiert werden. Anschliessend können die Zeitpunkte der Prüfungen definiert und mit der Durchführung der Software Tests gestartet werden. Das Testen der Software wird die Qualität insgesamt und im Detail verbessern.

Idee: weshalb nicht gleich die Spezifikation mit Testfällen erstellen?

Mit der Beschreibung von Vorbedingungen, verschiedenen und auch alternativen Aktionen könnte doch auch direkt eine Spezifikation erstellt werden - …? Damit könnte der gesamthaft zu erbringende Aufwand (zuerst Anforderungen und dann Testfälle spezifizieren) reduziert werden. Ebenfalls scheint es wahrscheinlich zu sein, dass damit die Qualität insgesamt verbessert wird. Die Formulierung und Beschreibung muss fast zwingend breit abgestützt und durch mehrere Beteiligte erfolgen, somit wird bereits frühzeitig über konkrete Anforderungen abgestimmt. So quasi erfolgt fast unbemerkt eine weitere Testschlaufe. Nachteilig könnte sein, dass das erforderliche Wissen der erst später einsehbaren, konkreten Softwarelösungen noch gar nicht in genügendem Umfang vorhanden ist. Ebenfalls erschwerend könnte sein, dass man die möglichen Vorteile der Software (und die Erfahrungen der Anbieterin) mit diesem Vorgehen und in Bezug auf optimale Prozesse tendenziell vernachlässigen könnte.

Es ist nicht ratsam, sich stur an einem Vorgehen festzuhalten. Sich frühzeitig Gedanken zum Testen zu machen und sich im ganzen Team damit auseinanderzusetzen hingegen schon.