Software Testing, Teil 1

Einführung in Testbereiche und Varianten

| Autor / Redakteur: Mirco Lang / Stephan Augsten

Die einfachste Art von Tests: Automatisierte Syntax-Checks, hier online bei ShellCheck.com.
Die einfachste Art von Tests: Automatisierte Syntax-Checks, hier online bei ShellCheck.com. (Bild: Lang / Shellcheck.com)

Jeder Software-Entwickler ist gleichzeitig auch Software-Tester – denn zumindest die selbst geschriebenen Funktionen spielt wohl jeder auch durch. Aber darüber hinaus? Das Feld der Tests reicht von einzelnen Units bis zur fertigen Software als Ganzes. Und in diesem weiten Feld gibt es etliche unterschiedliche Arten von Tests.

Das Testen von Software ist ein integraler Bestandteil der Software-Entwicklung – angefangen vom Entwickler selbst, der seine eben erstellte Schleife mit ein paar Testwerten durchlaufen lässt, bis hin zum Endkunden, der das fertige Produkt als Beta-Tester im Arbeitsalltag einsetzt.

Das Schöne am Testing: Hier sind allerlei unterschiedlichster Fähigkeiten gefragt, nicht nur Skills in der einen oder anderen Programmiersprache. In manchen Phasen sind hier auch Usability-Spezialisten, Manager, IT-Berater, Psychologen oder gar der berühmte DAU gefragt – der kommt nämlich manchmal auf Dinge und Einsatzmöglichkeiten, die technisch versiertem Personal nicht im Traum einfallen würden. ITler werfen nicht umsonst in Chats und Foren mit Facepalm-GIFs um sich.

Wer also Testing formal in die Entwicklung einbauen, sich fortbilden oder den Beruf des Testers ergreifen möchte, sollte zunächst eine Übersicht haben, was denn nun wo und wie getestet wird. Die Frage, wie im Detail getestet wird, könnte dann wiederum für jeden der folgenden Bereiche ganze Bücher füllen – sie könnte nicht nur, sie tut es.

Technische Ebenen

Die einfachste Art von Tests: Automatisierte Syntax-Checks, hier online bei ShellCheck.com.
Die einfachste Art von Tests: Automatisierte Syntax-Checks, hier online bei ShellCheck.com. (Bild: Lang / Shellcheck.com)

Im Allgemeinen unterscheidet man zunächst mal vier unterschiedliche Ebenen, auf denen Software getestet wird – eine sehr grobe Einteilung aus technischer Sicht. Es beginnt mit dem wohl bekanntesten Begriff, dem Unit Testing. Kurz gesagt ist damit schlicht und ergreifend das Testen einzelner Code-Abschnitte gemeint, also beispielsweise Ein- und Ausgabe einer Funktion.

Natürlich stehen solche Units nicht allein und werden in ein großes Ganzes integriert – woraus das Integration Testing folgt. Hier geht es darum, die Schnittstellen und das Verhalten zwischen einzelnen Modulen zu prüfen, zum Beispiel einer Login-Funktion und der zugehörigen Nutzerverwaltung.

Sind alle Teile integriert, steht letztlich das finale System, das eigentliche Software-Produkt zum Testen bereit. Während dieses System Testings werden dann zum Beispiel die vor der Entwicklung definierten Features aus der Anforderungsanalyse bzw. dem Lastenheft durchgespielt. Das können zum Beispiel Geschäftsvorfälle wie „Ware einbuchen, Ware verteilen, Ware liefern, Ware ausbuchen“ sein.

Wenn diese funktionalen Aspekte abgehakt sind, kann es an das Operation Acceptance Testing gehen. Hier geht es eher um das Umfeld der Software. Wie stabil läuft die Software in der Ziel-IT? Wie gut lässt sich das Produkt warten? Wie gut kann Support geleistet werden? Wie läuft das Recovery nach Ausfällen? Lässt sich das System auf eine neuere Betriebssystemversion migrieren?

OAT ist ein verhältnismäßig weiches Feld und macht eines ganz deutlich: Zum Testen genügen keine C#-Götter, es braucht auch Menschen mit einer managementmäßigen Übersicht.

Arten von Tests

Aus technischer Sicht spannender sind aber die vielen Techniken zum Testen bestimmter Aspekte einer Software. Und da finden sich in der Literatur oder auch in Beschreibungen von Entwicklern/Testern immer wieder dieselben Tests – alle mit ihrer eigenen Daseinsberechtigung.

Die folgende Aufstellung reißt kurz die wichtigsten Tests an und vermittelt einerseits einen Überblick das gesamte Testing-Spektrum und dient andererseits als Sprungbrett in die Tiefen der Details einzelner Konzepte. Bezogen auf die oben aufgespannten Ebenen, können einige Tests auf mehreren Ebenen laufen, andere nur auf einzelnen – wie auch der erste Kandidat.

Installation Testing

Der Installationstest befasst sich mit der Frage, wie die Software überhaupt zum Laufen kommt – ebenenmäßig kann das natürlich nur beim System Testing auftauchen. Interessant an diesem Bereich: Viele Projekte lassen Nutzer tatsächlich schon an dieser Stelle im Stich. Tools, die nicht über Binärpakete oder Paketmanager automatisch installiert werden können, benötigen oft manuell eingerichtete Abhängigkeiten und Konfigurationen – die beim Entwickler selbstverständlich vorhanden sind.

Während dieser Prüfung sollte Testern aber eben auch auffallen, dass es mit einem simplen Doppelklick oder Ähnlichem nicht getan ist. Es genügt hier einfach nicht, als Testergebnis festzuhalten, dass eine Software installiert werden kann – auch die Frage, ob die Dokumentation eindeutig und zuverlässig dorthin führt, muss bejaht werden. Dies nur mal als Beispiel, dass oft mehr hinter den Tests steckt, als man (Entwickler) meinen möchte.

Compatibility Testing

Hier wird geprüft, wie kompatibel die Software mit anderen Systemen ist, die für den Betrieb notwendig sind, also beispielsweise, ob der funkelnagelneue Social-Media-Dienst auch noch auf einem alten Windows Vista mit einem Internet Explorer Version 6 läuft – und nicht nur mit dem brandaktuellen System des Entwicklers.

Smoke Testing

Auch bekannt als Sanity Testing geht man hierbei der simplen Frage nach, ob eine Funktion grundlegend plausibel ist. Ziel ist es, ein schnelles Ergebnis zu haben und daraus schlussfolgern zu können, ob gründliche Tests überhaupt angebracht sind. Dafür kann man eine Reihe offensichtlicher Testfälle bemühen: Öffnet sich Feature XY, wenn man den Button betätigt? Startet das Programm überhaupt? Der Vorteil solcher Tests auf Offensichtlichkeiten: Es geht schnell und verhältnismäßig einfach und zeigt so sehr grundlegende Probleme.

Regression Testing

In diesem Fall macht man sich auf die Suche nach Fehlern, die durch Updates/Patches zustande gekommen sind; sprich Features, die früher funktionierten und dann plötzlich nicht mehr. Der Aufwand ist dabei unter Umständen enorm groß und kann fast alle der sonstigen Testarten nach sich ziehen; beispielsweise wenn eine Bibliothek ausgetauscht wird, auf die viele Features der Software zugreifen.

Acceptance Testing

Dies ist im Grunde ein Black-Box-Test auf Ebene des System Testings: Es wird geprüft, ob die definierten Anforderungen korrekt abgearbeitet werden – ohne sich dabei um technische Gründe dafür zu kümmern. Wird eine Software hier vom Kunden/Tester akzeptiert, kann es weitergehen – falls nicht, müssen weitere Tests (tendenziell auf der Ebene des Integration Testing) die Gründe offenlegen.

Alpha- und Beta-Testing kann man hier eigentlich subsumieren: Fertige Produkte werden intern beziehungsweise extern ohne explizite Testanweisungen auf Nutzer losgelassen, die aus ihrer persönlichen Sicht berichten, ob die Software so akzeptabel ist oder nicht.

Destructive Testing

Der wohl amüsanteste Part des Testens – hier darf und soll man hemmungslos kaputt machen! Es geht darum, Software aus dem Gleichgewicht zu bringen, indem sie zum Beispiel mit nicht dafür gedachten Daten gefüttert oder anders eingesetzt als vorgesehen wird. Daraus ergeben sich dann Empfehlungen bezüglich Fehler- und Ausnahmenbehandlung sowie Sicherheitsmaßnahmen (etwa die Verweigerung der Annahme bestimmter Daten/Zeichen).

Performance Testing

Eine Geschwindigkeitsanalyse versteht sich grundsätzlich wohl von selbst, knifflig wird's in der Praxis. Zum einen gibt es hier diverse Unterbereiche: Wie schnell arbeitet die Software? Wie stabil ist sie unter Stress? Wie skalierbar ist das Produkt? Hierfür müssen teils recht komplexe Testumgebungen existieren, um etwa eine Webanwendung „mal eben“ auf 200 parallel laufende Webserver auszurollen, mit Hunderten Terabyte Daten zu fluten und diese von Tausenden Clients gleichzeitig abrufen zu lassen. Hier sollte man viel Zeit für das exakte Design der Tests und der Messungen veranschlagen.

Usability Testing

Das Prüfen der Benutzbarkeit ist hingegen wieder ein weiches Spielfeld: Es geht hier nicht darum, ob einem User das Design gefällt oder nicht, Usability hat fixe Grundsätze, die sich überprüfen lassen. Dazu zählt beispielsweise, dass Dialoge selbsterklärend sind und Vorgänge sich abbrechen lassen. Dinge wie Erwartungskonformität lassen sich hingegen oft nur mit viel Aufwand testen: Ist der Button an der Stelle, wo der User ihn erwartet oder muss er erst suchen? Ohne Eye-Tracking ist das schwer zu sagen.

Accessiblity Testing

Hier kümmert man sich um die Zugänglichkeit der Software, also die Frage, inwiefern zum Beispiel sehbehinderte Nutzer mit der Software arbeiten können. Dafür gibt es allerlei Richtlinien und Standards, die beispielsweise bei Produktionen für den Bund oft vorgegeben werden.

Security Testing

Hinter den Sicherheitstests verbirgt sich nun wieder ein sehr, sehr weites Feld, das sich auf allen oben aufgezogenen Ebenen abspielt. Kurz gesagt geht es darum, die drei üblichen Schutzziele in Bezug auf die durch die Software verarbeiteten Daten zu verifizieren: Integrität, Vertraulichkeit und Verfügbarkeit – Aspekte, die natürlich in anderen Testbereichen mitmischen. Die Frage der Verfügbarkeit ist aus den Performance-Tests etwa kaum wegzudenken.

A/B Testing

Gehört auch zu den populäreren Buzzwords, meint aber etwas furchtbar Simples: Eine vorgeschlagene Änderung (B) wird im direkten Vergleich mit dem bestehenden Feature (A) getestet, um zu entscheiden, ob sich ein Update lohnt oder nicht.

Concurrent Testing

Gewissermaßen das Gegenstück zu Stresstests: Systeme werden automatisiert der realen Nutzung ähnlichen Bedingungen ausgesetzt, um quasi den Alltagsbetrieb gewährleisten zu können – jenseits von Lastspitzen, Hackerangriffen und dergleichen.

Conformance/Compliance Testing

Hierbei will man sicherstellen, dass sich Software an Standards und Vorgaben hält – seien es technische Aspekte wie die korrekte Arbeitsweise von Compilern oder juristische Rahmenwerke.

Zum Schluss noch zwei letzte Begriffe, die bei der Einordnung der vielen Testarten helfen: „Continuous Testing” kann sich im Grunde auf alle Testarten beziehen und meint schlicht, dass das Testen während des gesamten Entwicklungsprozesses stattfindet – also durchgängig und nicht zu bestimmten Zeitpunkten, was den Ablauf verzögern würde.

An vielen Stellen gibt es noch die Unterscheidung funktionaler und nicht-funktionaler Tests. Erstere kümmern sich um die definierten Anforderungen, die Entwickler mit ihrem Code umsetzen sollen. Letztere drehen sich um weiche Aspekte, um die Integration in IT-Landschaften, Performance Testing und in gewissem Maße auch die finale Akzeptanz. Funktionale Tests können bestimmen, ob eine Software funktioniert und die Anforderungen formal umsetzt, Nicht-funktionale Tests können eher aussagen, ob eine Software als Gesamtsystem gut ist.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45737832 / Testing)