Testmethoden im IT-Qualitätsmanagement

Die Notwendigkeit von IT-Qualitätsmanagement ist schnell erklärt: Funktioniert eine Website oder eine Anwendung nicht, ist der Nutzer weg! Im schlimmsten Fall für immer. Darunter leidet die Kundenzufriedenheit, der Umsatz und die Wettbewerbsfähigkeit. Damit dieser Fall möglichst nicht eintritt, wird IT Qualitätsmanagement eingesetzt, das bereits in der Konzeptions- und Entwicklungsphase greift und während des alltäglichen Betriebs der Anwendung kontinuierlich fortgeführt wird. Hierbei werden unterschiedliche Testmethoden eingesetzt. Katarina Apelt, Softwaretesterin bei Neofonie, stellt neben den wichtigsten Testmethoden auch mögliche Strategien und Prozesse kurz vor.

Je größer und komplexer Entwicklungsprojekte sind, desto höher ist die Wahrscheinlichkeit, dass sich Fehler, sog. „Bugs“, einnisten. Die können sich an den unterschiedlichsten Stellen verbergen: in den Schnittstellen, im Workflow, im Design, in den Funktionalitäten, im Payment, in der Performanz, im Caching, in der Datenbankverwaltung und so weiter, und so weiter. Manche Fehler sind ganz winzig, wirken sich aber dramatisch aus, manche Fehler sind kompliziert zu lösen, wirken sich aber nur minimal aus. Manche Fehler sind einfach zu finden und andere tarnen sich geschickt. Ebenso unterschiedlich wie die Fehlerarten sind, so unterschiedlich sind die Testverfahren, um die Bugs zu entdecken und letztlich zu eliminieren.

Wenn alles wichtig ist, ist nichts wichtig. Das gilt auch in der Softwareentwicklung. Da es unmöglich ist, alle Aspekte bis ins kleinste Detail zu überprüfen, soll eine Teststrategie Funktionalitäten priorisieren, auf die man sich dann während der Testphase konzentriert.

Die Wichtigkeit eines Features kann man dadurch ermitteln, wie hoch der oftmals finanzielle Schaden wäre, wenn dieses ausfällt oder nicht funktioniert.

Das International Software Testing Qualifications Board (ISTQB) definiert folgende Methoden als Teststrategien:

• top-down (Primäre, wichtige Funktionen werden vor sekundären getestet)

• bottom-up (Sekundäre Funktionen werden vor primären getestet)

• hardest first (wichtigste Funktion zuerst, potenzielle Blocker)

• Big-bang (alle Funktionen simultan)

Je nach Teamgröße und Ressourcen lässt sich dann entscheiden, welche Teststrategie sich anbietet und welche auch zu meistern ist. Unser Testingteam unterstützt Sie gerne dabei.

Im Unterschied zu herkömmlichen Testszenarien in einem Wasserfallprozess zeichnet sich agiles Testen darin aus, dass viel häufiger und schon früh in der Entwicklung dieselben Komponenten getestet werden. Voraussetzung dafür ist eine technische und organisatorische Infrastruktur (z.B. Tools für Archivierung und Build Prozesse und eine Definition of Done), die frühes Testen auch ermöglicht.

Da in der agilen Softwareentwicklung abgenommene Features häufig weiterhin geändert werden, muss das Testing nachziehen. Hierfür bieten sich insbesondere automatisierte Tests an, um schnell auf Feedback reagieren und angepasste Features testen zu können. Auf Code-Ebene werden Unit- und Integrationstest codiert. Auf GUI-Ebene können automatisierte Test möglichst früh nach Fertigstellung des Codes zumindest einfach angelegt werden.

Dadurch ist das Test-Team in das Entwicklungsteam integriert, im Gegensatz zu klassischen Projekten, wo das Test-Team erst zum Ende hin hinzugezogen wird. Durch die Integration von Test nach Entwicklung sowie die typischen Iterationen von 2 bis 3 Wochen, sind die Rollen Tester und Entwickler deutlich weniger voneinander abgegrenzt. Im Prinzip kann jeder im Team ein Tester sein und sein Feedback geben. Auch wenn es keinen dezidierten Testmanager gibt, muss das Team deren Aufgaben übernehmen. Dies umfasst das Planen von Tests, der Zeitschätzung, der Testdurchführung und Dokumentation.

Ob agil oder Wasserfall, in beiden Fällen braucht es ein strukturiertes Vorgehen beim Testing.

Zunächst beginnt man mit der Testplanung. Da Softwareentwicklung eine Menge Ressourcen benötigt und sich dahinter Kosten verbergen, sollte ein Plan alle Testaktivitäten des Projektes beinhalten und aufzeigen. Im Testplan finden sich Angaben zur Teststrategie, zum Testumfang, zu den Testzielen, der verwendeten Hilfssoftware wie z.B. das Automatisierungstool und der Vorgehensweise bei der Dokumentation. Auf die Planung können sich dann alle Teilnehmer berufen.

Nach der Planung folgt dann die Testvorbereitung. Hierfür werden alle Vorbereitungen getroffen, um das eigentliche Testing starten, auswerten und dokumentieren zu können. Dazu gehört eine Testumgebungen aufzusetzen, Tools zu konfigurieren oder eine Datenbank einzurichten.

Um einzelne Testfälle benennen zu können, braucht es Testspezifikationen. Dazu gehören Vorbedingungen, benötigte Daten und Hilfsmittel, Testschritte sowie das zu erwartende Testergebnis. In der agilen Praxis wird oft explorativ getestet, wo sich der Tester auf der Basis von den Anforderungen oder einer knappen Aufgabenstellung durch die Software klickt und die Testfälle sozusagen “on the fly” erstellen kann. Diese Testfälle fließen dann eventuell als Vorlagen in eine Testautomatisierung ein oder gehen in die allgemeinen Regressionstests. Bei kniffligen, umfangreichen Tests sollte der Testfall tatsächlich früher spezifiziert werden, weil es sich hier zeigt, dass so auch die Anforderungen qualitätsgesichert werden. Durch Verständnisfragen können Denkfehler in den Anforderungen erkannt werden, ehe sie implementiert sind.

Wurden die notwendigen Vorkehrungen getroffen, beginnt dann die Testdurchführung. Der Test-User beginnt den Test oder die Software für den automatisierten Test wird gestartet.
Nach der Durchführung folgt dann die Testauswertung. Es wird überprüft, ob das zu erwartende Ergebnis auftrat, oder ob es doch hierbei Abweichungen bzw. Fehler gibt. Die Ergebnisse aus den Tests werden dokumentiert. Über den Testbericht kann das Team später die Menge der gefundenen Abweichungen als durchschnittlich oder als Hinweis auf ein Problem im Softwareentwicklungsprozess bewerten und dann entsprechende Maßnahmen ergreifen.

Jedem Entwickler/ Tester graust es, sie anzufertigen, aber ohne Dokumentation gehen dem Team wichtige Informationen verloren. Auch in der agilen Entwicklung wird dokumentiert, aber möglichst nur so viel wie nötig, denn Dokumentation benötigt Pflege und neigt bei Teams mit verteilter Verantwortung zu Dopplungen.

Warum überhaupt dokumentieren: beispielsweise kann nur ein vernünftig beschriebener Fehlerfall schnell durch die Entwicklung behoben werden, weil es zu keinen Missverständnissen kommt. Ein verständliches Testkonzept, ein übersichtliches Anforderungsmanagement, eine ausführliche Dokumentation zu Best Practises, eine knappe DoD und weitere Dokumentationen sorgen dafür, dass neue Teammitglieder schnell eingearbeitet sind und die anderen am Ball bleiben können.

Im Bestfall findet sich in der Testdokumentation das Konzept (Vorgehensweise, Mittel, Ablauf), die einzelnen Spezifikationen (Soll-Zustand, Features) sowie das eigentliche Reporting (Aufzeichnung der Ereignisse). Die Standards für eine Testdokumentation werden im ISO 29119 festgehalten.

Hilfreich für Test-Dokumentationen sind Testmanagement Tools und Ticket Tools oder allgemein Tools für den Wissensaustausch.

Regressionstest

Die Pflege, Weiterentwicklung und Korrektur von Software-Code verursacht (neue) Fehler. Mit dem “regelmäßigen Wiederholen von Testfällen” wird geprüft, ob sich die Software nach den Änderungen weiterhin wie gewünscht verhält. Hierzu werden reale Testfälle mit einem klaren Soll-Ergebnis durchgeführt und mehrfach wiederholt. Dadurch wird sichergestellt, dass Modifikationen in bereits getesteten Teilen der Software zu keinen neuen Fehler führen. Regressionstests werden idealerweise automatisiert, weil das manuelle Testen aufgrund der Menge der Testfälle bei großen und langlebigen Projekten sehr zeitaufwendig wird.

Smoketest

Über den Smoketest werden die wichtigsten Komponenten der Anwendung oberflächlich und schnell auf kritische funktionale Fehler geprüft. Hierbei werden in limitierter Zeit die wichtigsten Funktionen und Komponenten einer Anwendung getestet. Fehler können schnell aufgedeckt werden, die je nach Schwere ein Release der Software verhindern würden.

Featuretest

Mit dem Featuretest werden insbesondere die neuen Funktionen der Software intensiv getestet. Beim Test von Bedieneroberflächen, dem sog. Frontend, wird aus Sicht des Nutzers getestet, dass übrigens eine große Herausforderung darstellt, da diese Sicht nicht immer mit der technischen Sichtweise übereinstimmt. Die Komplexität wird durch die Vielzahl der Internet-Browser, unterschiedlicher Betriebssysteme (iOS, Windows, Android) und Endgeräte (Desktop, Tablet, Smartphone) erhöht. Diese nutzerorientierte Testmethode berücksichtigt das Layout, das Wording und Ungereimtheiten oder Definitions-Lücken im Klick-Flow. Abweichungen, die dabei aufgedeckt werden, können relativ schnell beseitigt werden, da allen Beteiligten die neuen Funktionen und damit verbundenen Änderungen präsent sind.

Kundentest

Der Kunde testet vor der Liveschaltung auf einer separaten Umgebung selber. Je nach Absprache handelt es sich hier um eine festgelegte Menge Abnahmetests oder um umfangreiche Featuretests. Der entscheidende Mehrwert dieses integrierten Vorgehens: Je schneller die ersten Sprint-Ergebnisse vorliegen, desto früher erhalten die Kunden Einblick in den Entwicklungsprozess und können die Qualität mitgestalten sowie das Risiko falsch verstandener Absprachen minimieren.

Last- und Performancetest

Internetanwendungen mit viel Traffic müssen schnell und belastbar sein. Je nach Kundenanforderung und Absprache führen Qualitätssicherung, Entwicklung und ASP (Application Service Provider) Last- und Performancetests durch. Entwickler führen temporär entwicklungsbegleitende Lasttests durch, mit dem Ziel der Optimierung der Kennzahlen (Antwortzeiten, Durchsatz), mittels Tuning von Parametern bzw. Änderungen in der Applikations-Programmierung oder in anderen Fehlerquellen.

Die Tester führen Nutzer-Stresstests für jedes Release als Regressionstest auf einem Prelive-System durch. Sinn ist die Vergleichbarkeit der Kennzahlen zwischen den Releases. Ein positives Ergebnis wäre, wenn die gemessenen Werte mindestens genauso gut wie beim Vor-Release bleiben.

Datensicherheit

Das Thema Datensicherheit ist ein komplexes Themenfeld. Man kann bereits mit einfachen Mitteln die wichtigsten Security Checks durchführen, allerdings ist das keinesfalls mit einem Sicherheitsaudit zu vergleichen. Automatisiert können Vulnerability Scans für Webanwendungen durchgeführt werden, z. B. auf Basis des OWASP ZAP Webapplication Scanner mit dem Focus auf den OWASP Top 10 (Sicherheitsrisiken für Webanwendungen). Zudem gibt es automatisierte Regressionstests bzw. Integrationtests auf Selenium/Java-Basis, die regelmäßig über z. B. Jenkins ausgeführt werden. Diese Tests prüfen auf der Weboberfläche, ob bestimmte durch die Entwicklung behobene Sicherheitslücken trotz fortlaufender Änderungen im Code unauffällig bleiben. Diese Tests leiten sich vor allem aus den Ergebnissen von IT-Sicherheitsaudits ab.

Barrierefeiheit

Testmöglichkeiten zur Barriere-Freiheit sind zahlreich, sowohl für den White-Box-Bereich (WCAG 2.0 über Test Tools) als auch den Black-Box-Bereich (Prüfkataloge nach W3C oder BITV).

User-Acceptance-Testing (UAT)

Bei einem User-Acceptance-Test wird die Anwendung in einer Beta-Phase von ausgewählten Endnutzern getestet. Mit den Nutzern werden dann Szenarien durchgegangen und notiert, wie sie sich unvoreingenommen durch die Anwendung bewegen und wie diese die Funktionen verwenden. Die Nutzer werden nur geleitet, ohne zu sehr Einfluss auf ihre Nutzung zu nehmen. Oftmals zeigen sich Verhaltensweisen, die man während der Entwicklung nicht bedacht hat und kann somit neue User Journeys ausfindig machen.

Integrationstest

Eine Software ist oftmals in einem digitalen Ökosystem mit vielen Abhängigkeiten und Verweisen eingebettet. Ein Integrationstest überprüft hierbei eine Anwendung in seiner Systemumgebung mit all den integrierten und umliegenden Komponenten. Es wird geprüft, ob ein reibungsloser Ablauf in diesem System gewährleistet werden kann oder ob doch gewisse Abhängigkeiten und Verweise Fehler aufwerfen.

Entscheidungstabellentest

In einem Entscheidungstabellentest werden alle möglichen Kombinationen überprüft und dokumentiert. Gerade bei Features, die mehrere Logiken abbilden, ist ein solcher Test ziemlich hilfreich.

Grenzwertanalyse

Damit man nicht alle Werte bei Eingaben testen muss, reicht es aus, wenn man sich nur die Grenzwerte anschaut, bei denen eine gültige bzw. ungültige Eingabe auftritt.

Hardware-Test

Auch bei der Softwareentwicklung muss man die Hardware mitbedenken.

Hierzu wird insbesondere bei Plattentests überprüft, ob die Hardware der verwendeten Server die Netzlast oder die Zugriffszeit stemmen können, ohne bei zu langer Beanspruchung Schaden zu nehmen.

Statische Tests

Bei statischen Tests wird die Software selbst nicht ausgeführt. Man unterzieht die Software einer sog. Code-Review, wo man analytisch die einzelnen Code-Zeilen durchgeht und nach ihrer Sinnhaftigkeit überprüft. Beispielsweise kann mithilfe einer Datenflussanalyse überprüft werden, welche Daten herangezogen und weitergegeben werden und ob dies den Anforderungen entspricht.

Sinnvoll ist hier der Einsatz eines Tools, welches den Quellcode mit Hilfe von konfigurierbaren Regeln automatisiert durchdringt und das Ergebnis reported.

Whitebox-Test

Whitebox-Testverfahren bezeichnen eine Testmethode, in der mithilfe des Quellcodes Testszenarien entworfen werden. Beispielsweise geht es hier um Unittests und Integrationstest, die für das agile Testen so wichtig sind, und um die statische Analyse des Quellcodes.

Die Bezeichnung Whitebox rührt daher, dass man quasi ins System hineinschauen kann, also sich den Code zunutze macht. Der Tester kennt den Code, seinen Aufbau und seine Funktionsweise.

Der Vorteil der Whitebox-Testverfahren liegen auf der Hand: Unittests werden mit jedem Software-Build als Regressionstests ausgeführt, sie lassen sich schnell ausführen und sie bieten über die statische Softwareanalyse ein Maß der Testabdeckung im Code. Bei testgetriebener Entwicklung zwingen sie die Entwicklung zur Qualität in der Softwarearchitektur.

Der Nachteil von solchen Tests ist, dass sie bei der Entwicklung Ressourcen verschlingen.

Blackbox-Test

Im Gegensatz zu Whitebox-Test kennt der Tester im Blackbox-Test den Code nicht. Daher auch die namensgebende Blackbox. Es wird hauptsächlich das sichtbare Ergebnis überprüft.

Der Vorteil von Blackbox-Tests ist, dass hier die Software aus der Sicht des Endnutzers eingenommen wird.

Content-Test

Neben den eigentlichen Funktionen einer Software ist der Inhalt in gleichem Maße entscheidend. Bei dem Content Test wird der komplette Inhalt der Software auf Richtigkeit und Tonalität getestet und überprüft. Gerade bei Anwendungen mit multinationalen Inhalten ist es wichtig sicherzustellen, dass jede Ländervariante auch die passenden Inhalten in der jeweiligen Sprache aufweist.

Klassifikationsbaummethode

Auch wenn es der Name vermuten lässt, hat die Klassifikationsbaummethode nichts mit Entscheidungsbäumen zu tun.

Die von Matthias Grochtmann und Klaus Grimm konzipierte Methode basiert auf zwei Stufen.

Im ersten Schritt werden alle Aspekte aufgeschlüsselt, die für den Test relevant sind. Das sind die sog. Klassifikationen. Die einzelnen Ausprägungen der Klassifikationen sind als Klassen zu verstehen. Wenn man bspw. Benutzerrollen (Klassifikation) testen möchte, dann müsste man sich die Rechte von normalen Nutzern und einem Admin-Nutzer (Klassen) genauer anschauen.

Ist dies abgeschlossen, kombiniert man die einzelnen Klassen innerhalb der Klassifikationen und erstellt dadurch Testfälle.

Ein Testfall kann dann sein: Normaler Nutzer möchte einen neuen Artikel erstellen.

Bei all den aufgezeigten Testmethoden können verschiedene Fehlerarten auftauchen, die nicht das gewünschte Ergebnis zeigen.

Syntaxfehler treten auf, wenn der Code nicht in der vorgesehenen Abfolge programmiert wurde. Bei Syntaxfehlern lässt sich der Code dann nicht kompilieren, also in Maschinensprache umwandeln.

Bei einem Semantikfehler wird der Code korrekt ausgeführt und kompiliert, aber trotzdem erscheint weiterhin nicht das gewünschte Ergebnis.

Laufzeitfehler treten dann auf, wenn das Programm gerade ausgeführt wird. Oftmals werden bei solchen Fehlerarten gewisse Werte überschritten.

Logische Fehler liegen meist darin begründet, dass der Entwickler meist fehlerhafte Berechnungen in den Code einbaut oder dieser falsch abläuft.

Designfehler liegen schon im Konzept begründet, noch bevor die erste Zeile Code geschrieben wurde. So können falsche Anforderungen an die Software durch mangelnde Kenntnisse aufgestellt worden sein, die sich im Nachgang als sinnlos erweisen.

Auch bei der Softwareentwicklung lautet das Credo: If it’s not tested, it doesn’t work! Mit verschiedenen Testmethoden, -strategien und -prozessen können Sie das Qualitätsniveau Ihrer Anwendung hochhalten und Ihren Nutzern ein einwandfreies Erlebnis bieten!

Veröffentlichung am 27.04.2015, aktualisiert am 25.11.2021