Testing und Qualitätssicherung (Webdevelopment)

Testing und Qualitätssicherung für Web-Anwendungen

Fehler, Qualitätsmängel oder Ausfälle von Web-Anwendungen haben oft gravierende Auswirkungen auf den Umsatz, die Kundenzufriedenheit und den Ruf eines Unternehmens. Aus der Perspektive der Wirtschaftsinformatik ist es daher wichtig, Qualitätssicherung (QS) und Testing nicht nur als technische Notwendigkeit zu betrachten, sondern als Instrumente zur Risikominimierung. Es gilt, die technischen Aspekte der Softwarequalität – wie Zuverlässigkeit, Performance oder Sicherheit – in betriebswirtschaftliche Kennzahlen und übergeordnete Geschäftsziele zu übersetzen und deren Beitrag zum Unternehmenserfolg messbar zu machen.

Ein zentrales Konzept zur Bewertung der Wirtschaftlichkeit von Qualitätsmaßnahmen ist das Modell der Qualitätskosten (Cost of Quality, CoQ). Dieses Modell differenziert zwischen Fehlerverhütungskosten (Kosten zur Vermeidung von Fehlern, z.B. durch Schulungen, Reviews oder verbesserte Designprozesse), Prüfkosten (Kosten für die Bewertung der Produktqualität, z.B. durch Tests und Inspektionen), internen Fehlerkosten (Kosten für Fehler, die vor Auslieferung an den Kunden entdeckt werden, z.B. Nachbesserungsaufwand, Ausschuss) und externen Fehlerkosten (Kosten für Fehler, die erst beim Kunden auftreten, z.B. Supportaufwand, Garantieleistungen, Reputationsschäden, Kundenverlust). Die sogenannte "1-10-100-Regel" verdeutlicht praxisnah die Eskalation dieser Kosten: Ein Fehler, dessen Behebung in der Designphase einer Web-Anwendung beispielsweise 1€ kostet, kann in der Testphase bereits 10€ und im Live-Betrieb 100€ oder ein Vielfaches davon verursachen. Ein konkretes Beispiel hierfür wäre ein Designfehler in der Navigationsstruktur einer E-Commerce-Anwendung. Wird dieser Fehler frühzeitig durch Usability-Reviews entdeckt, sind die Verhütungskosten gering. Erfolgt die Entdeckung erst während des Systemtests, entstehen bereits signifikante interne Fehlerkosten durch notwendiges Redesign, erneute Implementierung und wiederholte Testläufe. Fällt der Fehler jedoch erst nach dem Go-Live durch Kundenfeedback auf, können die externen Fehlerkosten durch Supportanfragen, verlorene Verkaufsabschlüsse und einen Imageschaden groß sein.

Der Business Value von Qualitätssicherung definiert sich somit nicht nur in der Senkung direkter Fehlerkosten. Frühzeitige und kontinuierliche Qualitätssicherung steigert darüber hinaus die Effizienz der Entwicklungsprozesse, verkürzt die Time-to-Market neuer Funktionen oder Produkte und erhöht die Kundenzufriedenheit sowie die Kundenbindung, was sich wiederum positiv auf den Umsatz auswirkt. 

Die fortschreitende Digitalisierung und die damit einhergehende, stetig wachsende Komplexität von Web-Anwendungen, beispielsweise durch den Einsatz von Microservice-Architekturen oder die Integration von Künstlicher Intelligenz, erhöhen den Stellenwert einer proaktiven und intelligenten QS-Strategie exponentiell. Traditionelle, oft reaktive Testansätze stoßen hier schnell an ihre Grenzen. Moderne Ansätze wie "Shift Left"-Testing, DevSecOps und KI-gestütztes Testen sind nicht mehr nur wünschenswert, sondern notwendig, um diese Komplexität zu beherrschen und qualitativ hochwertige Web-Anwendungen zuverlässig auszuliefern. 

Es ist wichtig, verschiedene Testmethoden und -werkzeuge zu kennen, aber auch ein tiefgreifendes Verständnis dafür zu entwickeln, wie QS-Prozesse in moderne, agile und hochautomatisierte Entwicklungs-Pipelines integriert werden können. Die Fähigkeit, die richtigen QS-Strategien für komplexe digitale Produkte auszuwählen, zu implementieren und deren Beitrag zum Geschäftserfolg zu optimieren und zu kommunizieren, entwickelt sich zu einer entscheidenden Kernkompetenz.

Grundlagen des Testens: Prinzipien und Prozessorientierung

Ein solides Fundament im Testen von Software basiert auf etablierten Prinzipien und einem strukturierten Prozessverständnis. Diese Grundlagen sind entscheidend, um Testaktivitäten effektiv zu planen, durchzuführen und zu bewerten, insbesondere im dynamischen Umfeld der Web-Anwendungsentwicklung.

Die Sieben Grundprinzipien des Testens (nach ISTQB) – Praxisbezug für Web-Anwendungen:

Das International Software Testing Qualifications Board (ISTQB) hat sieben Grundprinzipien formuliert, die als Leitlinien für jegliche Testaktivitäten dienen und für die Qualitätssicherung von Web-Anwendungen von hoher Relevanz sind.4

1. Testen zeigt die Anwesenheit von Fehlern, nicht deren Abwesenheit: Selbst eine intensiv getestete Web-Anwendung kann verborgene Fehler enthalten. Das Ziel der QS ist es, das Risiko kritischer Fehler zu minimieren und Vertrauen in die Qualität zu schaffen, nicht absolute Fehlerfreiheit zu garantieren. Beispielsweise kann ein E-Commerce-Shop auf hunderte von Kaufszenarien getestet werden; ein seltener Edge Case oder eine ungewöhnliche Benutzerinteraktion kann dennoch unentdeckt bleiben.
2. Vollständiges Testen ist unmöglich: Angesichts der immensen Kombinationsvielfalt von Eingabewerten, Benutzerpfaden, Browsern, Betriebssystemen und Endgeräten bei Web-Anwendungen ist ein hundertprozentiger Test aller denkbaren Szenarien praktisch nicht realisierbar. Risikobasierte Ansätze und die Priorisierung von Testfällen sind daher unerlässlich. Eine komplexe Web-Anwendung mit zahlreichen Formularen, dynamischen Inhalten und vielfältigen Benutzerinteraktionen kann nicht jede einzelne Permutation testen.
3. Frühes Testen spart Zeit und Geld (Shift Left): Fehler, die bereits in frühen Phasen des Entwicklungszyklus einer Web-Anwendung – wie der Anforderungsanalyse oder dem Design – identifiziert und behoben werden, verursachen signifikant geringere Kosten als Fehler, die erst in späteren Testphasen oder gar im Live-Betrieb entdeckt werden. Ein Missverständnis in den Anforderungen für eine Benutzerberechtigungsmatrix einer Web-Anwendung, das frühzeitig durch ein Review aufgedeckt wird, verhindert aufwendige und teure Umprogrammierungen zu einem späteren Zeitpunkt.
4. Fehler treten gehäuft auf (Defect Clustering): Die Erfahrung zeigt, dass oft eine kleine Anzahl von Modulen oder Komponenten einer Web-Anwendung für die Mehrheit der gefundenen Fehler verantwortlich ist. Testressourcen sollten daher gezielt auf diese risikoreichen Bereiche konzentriert werden. Beispielsweise sind das Zahlungsmodul oder die Integration von Drittanbieter-APIs in einem Web-Shop oft fehleranfälliger als statische Inhaltsseiten.
5. Tests nutzen sich ab (Pestizid-Paradoxon): Wenn für eine Web-Anwendung über längere Zeit immer dieselben Testfälle wiederholt werden, sinkt deren Effektivität bei der Entdeckung neuer Fehler. Testfälle müssen daher regelmäßig überprüft, angepasst und erweitert werden, um mit den Weiterentwicklungen der Anwendung Schritt zu halten. Werden beispielsweise neue Authentifizierungsmethoden wie Zwei-Faktor-Authentifizierung in einer Web-Anwendung eingeführt, müssen bestehende Regressionstests für die Login-Funktion entsprechend erweitert werden.
6. Testen ist kontextabhängig: Die Teststrategie und -intensität müssen an den spezifischen Kontext der Web-Anwendung angepasst werden. Eine einfache Informations-Website erfordert andere Testschwerpunkte und -verfahren als ein Online-Banking, ein komplexer E-Commerce-Shop oder eine sicherheitskritische Regierungsanwendung. Eine Banking-Anwendung erfordert beispielsweise intensive Sicherheitstests und die Prüfung komplexer Transaktionslogiken, während bei einem Unternehmensblog der Fokus eher auf Usability, korrekter Content-Darstellung und Suchmaschinenoptimierung liegen könnte.
7. Trugschluss: „Keine Fehler“ bedeutet ein brauchbares System: Eine Web-Anwendung kann technisch fehlerfrei sein, aber dennoch die Anforderungen der Benutzer nicht erfüllen, eine schlechte User Experience bieten oder geschäftliche Ziele verfehlen und somit wertlos sein. Eine Web-Anwendung zur Reisebuchung mag technisch einwandfrei funktionieren, aber wenn der Buchungsprozess für die Nutzer umständlich, verwirrend oder langsam ist, werden sie die Anwendung verlassen und zur Konkurrenz wechseln.

Der Fundamentale Testprozess nach ISTQB und seine agile Anpassung

Der ISTQB definiert einen fundamentalen Testprozess, der als Rahmen für die Durchführung von Testaktivitäten dient. Dieser Prozess umfasst typischerweise die Phasen: Testplanung, Testanalyse, Testentwurf, Testrealisierung, Testdurchführung und Testabschluss.

Im Kontext agiler Entwicklungsmethoden wie Scrum oder Kanban, die in Web-Projekten weit verbreitet sind, erfährt dieser klassische Prozess eine signifikante Anpassung. Anstelle langer, sequenzieller Phasen treten kürzere Zyklen, eine kontinuierliche Integration von Testaktivitäten in die Sprints und eine enge, tägliche Zusammenarbeit im gesamten Team (Entwickler, Tester, Product Owner). Der Fokus liegt auf schnellem Feedback und der iterativen Verbesserung der Softwarequalität.

Die Testplanung wird zu einer kontinuierlichen und iterativen Aktivität. In der Release- und Sprint-Planung werden Testaufwände geschätzt und Risikobewertungen vorgenommen.

Testanalyse und -entwurf erfolgen parallel zur Definition und Verfeinerung von User Stories und deren Akzeptanzkriterien. Die Testdurchführung ist in agilen Web-Projekten stark automatisiert und tief in Continuous Integration/Continuous Delivery (CI/CD)-Pipelines integriert, um schnelles Feedback zu Codeänderungen zu ermöglichen. Der Testabschluss findet nicht nur am Ende des gesamten Projekts statt, sondern iterativ am Ende jedes Sprints, beispielsweise in Form von Retrospektiven und der Dokumentation von Lessons Learned, um den Prozess kontinuierlich zu verbessern.

Testdokumentation in agilen Web-Projekten

In agilen Projekten wird von umfangreichen, detaillierten Testplänen und -spezifikationen zugunsten pragmatischerer und flexiblerer Testartefakte Abstand genommen. Ziel ist eine Dokumentation, die den Prozess unterstützt, statt ihn zu behindern.

* Test Charters sind ein nützliches Werkzeug für das explorative Testen. Sie definieren in kurzer, prägnanter Form den Auftrag, den Umfang, die Ressourcen und die Ziele einer explorativen Testsitzung. Ein Beispiel für einen Test Charter könnte lauten: "Erkunden Sie die neue Checkout-Seite des Web-Shops mit verschiedenen Zahlungsmethoden auf unterschiedlichen mobilen Endgeräten, um potenzielle Usability-Probleme und Fehler im Bezahlprozess unter realitätsnahen Bedingungen zu entdecken."

* Mindmaps eignen sich hervorragend zur visuellen Strukturierung von Testideen, zur Abdeckung von Testbereichen oder zur kollaborativen Erstellung von Testplänen. Sie fördern die Kreativität und das gemeinsame Verständnis im Team.

* Checklisten dienen als Gedächtnisstütze für wiederkehrende Prüfungen, beispielsweise im Rahmen von Release-Freigaben, zur Überprüfung der Einhaltung von Qualitätsstandards oder für Smoke-Tests nach einem Deployment.

In traditionellen Modellen agieren Testteams oft isoliert und werden erst spät im Entwicklungsprozess involviert. Agile Methoden hingegen verstärken die kontinuierliche Zusammenarbeit und die gemeinsame Verantwortung des gesamten Teams für die Softwarequalität. Für Web-Projekte mit ihren typischerweise schnellen Release-Zyklen ist diese enge Verzahnung von Entwicklung und Test unerlässlich, um Qualität von Anfang an "einzubauen" (Built-in-Quality) anstatt sie nur am Ende "anzuprüfen". 

Dokumentation

Eine “leichtgewichtige” Dokumentation in agilen Projekten bedeutet nicht, dass zu großen Teilen auf Dokumentation verzichtet wird. Vielmehr geht es um eine effektive und zweckdienliche Dokumentation. Agile Prinzipien warnen vor einer "umfassenden Dokumentation" als Selbstzweck. Dennoch ist ein gewisses Maß an Dokumentation für die Nachvollziehbarkeit, den Wissenstransfer und insbesondere bei regulierten Projekten oder komplexen Systemen unerlässlich. Test Charters, Mindmaps und Checklisten sind Beispiele dafür, wie Dokumentation schlank und wertstiftend gestaltet werden kann. Der wichtigste Aspekt aus Blick der Wirtschaftsinformatik liegt im Management des Trade-offs zwischen der gewünschten Agilität und der notwendigen Dokumentationstiefe. Es gilt, Tools und Methoden zu kennen und einzusetzen, die diesen Spagat unterstützen, mit dem Ziel einer "just enough" Dokumentation, die den Prozess effektiv unterstützt, statt ihn unnötig zu belasten.

Testarten und -verfahren

Für die umfassende Qualitätssicherung von Web-Anwendungen steht ein breites Spektrum an Testarten und -verfahren zur Verfügung. Diese lassen sich grob in funktionale und nicht-funktionale Tests unterteilen und werden durch spezifische Testfallentwurfsmethoden konkretisiert.

Funktionale Tests: Sicherstellung der korrekten Funktionsweise

Funktionale Tests überprüfen, ob die Web-Anwendung die in den Anforderungen spezifizierten Funktionen korrekt und vollständig ausführt – sie beantworten die Frage: "Tut die Software das Richtige?".56 Für den Entwurf effektiver funktionaler Testfälle kommen verschiedene Black-Box-Methoden nach ISTQB zum Einsatz:

Äquivalenzklassenbildung: Dieses Verfahren reduziert die Anzahl der notwendigen Testfälle, indem Eingabedaten in Äquivalenzklassen gruppiert werden. Es wird davon ausgegangen, dass alle Werte innerhalb einer Klasse das gleiche Verhalten der Software hervorrufen.

Praxisbeispiel Web-Formular (Alterseingabe): Ein Eingabefeld für das Alter akzeptiert Werte zwischen 18 und 99 Jahren.

Gültige Äquivalenzklasse: Zahlen von 18 bis 99 (z.B. Test mit Repräsentant: 30).

Ungültige Äquivalenzklassen: Zahlen kleiner als 18 (z.B. Repräsentant: 10), Zahlen größer als 99 (z.B. Repräsentant: 110), nicht-numerische Eingaben (z.B. Repräsentant: "ABC"), leere Eingabe.

Grenzwertanalyse: Diese Methode ergänzt die Äquivalenzklassenbildung und konzentriert sich auf die "Ränder" oder Grenzen der definierten Äquivalenzklassen, da hier erfahrungsgemäß häufig Fehler auftreten.

Praxisbeispiel Web-Formular (Alterseingabe 18-99): Relevante Testwerte wären 17 (ungültig, untere Grenze -1), 18 (gültig, untere Grenze), 99 (gültig, obere Grenze) und 100 (ungültig, obere Grenze +1).

Entscheidungstabellentests: Dieses Verfahren ist besonders nützlich für die Überprüfung komplexer Geschäftsregeln, bei denen mehrere Bedingungen zu unterschiedlichen Aktionen oder Ergebnissen führen.

Praxisbeispiel Web-Shop Rabattsystem: Bedingungen könnten sein: Kundenstatus (z.B. Standard, Premium), Bestellwert (z.B. <50€, 50-100€, >100€) und Vorhandensein eines gültigen Gutscheincodes. Mögliche Aktionen wären: Kein Rabatt, 5% Rabatt, 10% Rabatt, Fehlermeldung bei ungültigem Gutschein. Jede Regel in der Entscheidungstabelle, die eine spezifische Kombination von Bedingungsausprägungen und die daraus resultierende Aktion darstellt, wird zu einem Testfall.

Zustandsübergangstests: Diese Technik modelliert und testet das Verhalten eines Systems, das sich aufgrund von Ereignissen oder Benutzeraktionen durch verschiedene Zustände bewegt.

Praxisbeispiel Benutzer-Login einer Web-Anwendung: Mögliche Zustände sind: "Abgemeldet", "Anmeldeversuch" (Benutzername/Passwort eingegeben), "Angemeldet", "Konto temporär gesperrt". Ereignisse könnten sein: Eingabe gültiger Anmeldedaten, Eingabe ungültiger Anmeldedaten, dreimalige Falscheingabe, Anforderung "Passwort vergessen". Aktionen wären beispielsweise die Weiterleitung zum Benutzer-Dashboard, die Anzeige einer Fehlermeldung oder die Sperrung des Kontos. Testfälle werden entworfen, um sowohl gültige Übergänge (z.B. erfolgreicher Login) als auch ungültige oder Fehlerübergänge (z.B. fehlgeschlagener Login, Sperrung des Kontos nach zu vielen Fehlversuchen) abzudecken.

Praxisbeispiele für funktionale Tests in verschiedenen Web-Anwendungen sind vielfältig:

• Benutzerverwaltung: Testen der Registrierung mit gültigen und ungültigen Daten, Login- und Logout-Prozesse, Passwort-Reset-Funktionen, Aktualisierung von Profilinformationen sowie die Überprüfung von Rollen- und Rechtekonzepten.
• Suchfunktion: Überprüfung der Suchergebnisse bei verschiedenen Suchkriterien, korrekte Anwendung von Filtern und Sortieroptionen, Verhalten der Anwendung bei keinen Suchtreffern und die Performance der Suche bei großen Datenmengen.
• Warenkorb & Bestellprozess (E-Commerce): Testen des Hinzufügens und Entfernens von Artikeln zum/aus dem Warenkorb, Mengenänderungen, korrekte Preisberechnung (inklusive Steuern, Versandkosten), Einlösung von Gutscheinen, Validierung von Lieferadressen, Simulation verschiedener Zahlungsabwicklungen und Überprüfung der Bestellbestätigung.
• Content Management Systeme (CMS): Testen der Erstellung, Bearbeitung und Löschung von Inhalten, Upload und Verwaltung von Mediendateien, Workflow-Tests (z.B. Freigabeprozesse für Artikel) und die korrekte Funktionsweise verschiedener Benutzerrollen im CMS.
• Online-Buchungssysteme (z.B. für Flüge, Hotels, Events): Überprüfung der Verfügbarkeitsanzeige, korrekte Auswahl von Optionen (z.B. Datum, Uhrzeit, Sitzplatz, Zimmerkategorie), Preisberechnungen (inkl. Zusatzleistungen), Versand von Buchungsbestätigungen und die Funktionalität von Stornierungsprozessen.

Nicht-funktionale Tests: Absicherung der Qualitätseigenschaften

Nicht-funktionale Tests bewerten, wie gut die Web-Anwendung ihre Funktionen ausführt. Sie orientieren sich an Qualitätsmerkmalen, wie sie beispielsweise in der Norm ISO/IEC 25010 definiert sind: Zuverlässigkeit, Benutzbarkeit (Usability), Effizienz (Performance), Wartbarkeit, Portabilität, Sicherheit und Kompatibilität.

Performancetests

Performancetest untersuchen das Zeit- und Lastverhalten der Web-Anwendung.

Lasttests: Simulieren die erwartete maximale Benutzerlast, um sicherzustellen, dass die Anwendung die definierten Antwortzeitkriterien erfüllt und stabil bleibt. Ein typisches Szenario ist die Überprüfung eines E-Commerce-Shops während einer Black-Friday-Aktion, bei der beispielsweise 10.000 gleichzeitige Nutzer bedient werden müssen, wobei die Antwortzeiten unter zwei Sekunden bleiben sollen.

Stresstests: Setzen die Anwendung einer Last aus, die über die erwarteten Maximalwerte hinausgeht, um Systemgrenzen zu identifizieren und das Verhalten bei Überlast (z.B. kontrollierte Drosselung, Fehlermeldungen, Absturzverhalten) zu analysieren. Wie reagiert der Web-Shop, wenn plötzlich 20.000 Nutzer gleichzeitig zugreifen? Bricht er unkontrolliert zusammen oder werden Zugriffe geordnet verwaltet?

Dauerlasttests (Endurance Tests): Überprüfen die Stabilität und Ressourcennutzung der Anwendung über einen längeren Zeitraum unter kontinuierlicher Last, um beispielsweise Speicherlecks (Memory Leaks) oder Performance-Degradation aufzudecken. Läuft ein internes Berichtsportal auch nach 24 Stunden Dauerbetrieb mit 500 Usern noch stabil und performant?

Usability-Tests

Usability-Tests zielen darauf ab, eine positive und effiziente User Experience (UX) sicherzustellen.

Heuristische Evaluation: Usability-Experten bewerten die Benutzeroberfläche (UI) anhand anerkannter Usability-Prinzipien und -Heuristiken, um potenzielle Schwachstellen in der Benutzerführung zu identifizieren.100

A/B-Tests: Vergleichen zweier oder mehrerer Varianten einer Webseite oder eines Features (z.B. unterschiedliche Button-Farben, Texte für Call-to-Actions, Layout-Varianten), um empirisch zu ermitteln, welche Version besser bei den Nutzern ankommt oder zu höheren Konversionsraten führt.4

Weitere Methoden: Beobachtung von Nutzern bei der Interaktion mit der Anwendung, Card Sorting zur Optimierung der Informationsarchitektur, Erstellung von Personas zur Veranschaulichung der Zielgruppen, Eye Tracking zur Analyse des Blickverhaltens, Fokusgruppen zur Erhebung von Meinungen und Wünschen sowie Online-Umfragen zur Sammlung quantitativen und qualitativen Feedbacks.

Kompatibilitätstests: Stellen sicher, dass die Web-Anwendung mit einer Vielzahl von Plattformen korrekt funktioniert und dargestellt wird.

Browserkompatibilität: Testen auf den gängigsten Webbrowsern (z.B. Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge) und deren relevanten Versionen.

Betriebssystemkompatibilität: Überprüfung auf verschiedenen Betriebssystemen wie Windows, macOS, Linux sowie mobilen Betriebssystemen wie iOS und Android.

Gerätevielfalt: Testen auf unterschiedlichen Endgeräten, darunter Desktops, Laptops, Tablets und Smartphones mit verschiedenen Bildschirmgrößen und Auflösungen.

Responsive Design Testing: Überprüfung, ob sich das Layout und die Funktionalität der Web-Anwendung dynamisch und korrekt an verschiedene Bildschirmgrößen und Ausrichtungen (Hoch-/Querformat) anpassen. Zu den Herausforderungen gehören die enorme Vielfalt der Viewports, unterschiedliche Interaktionsmuster (Touch vs. Maus) und die Sicherstellung einer guten Performance auf mobilen Endgeräten. Techniken umfassen manuelles Testen auf echten Geräten, den Einsatz von Emulatoren und Simulatoren, die Nutzung von Browser-Entwicklertools zur Simulation verschiedener Geräte und automatisierte visuelle Regressionstests.

Barrierefreiheitstests (Accessibility Testing)

Sicherstellung, dass Web-Anwendungen auch von Menschen mit unterschiedlichen Behinderungen (z.B. Seh-, Hör-, motorischen oder kognitiven Einschränkungen) uneingeschränkt genutzt werden können.

Die Grundlage hierfür bilden die international anerkannten Web Content Accessibility Guidelines (WCAG). Diese definieren vier Prinzipien, nach denen Webinhalte gestaltet sein sollten: Wahrnehmbar, Bedienbar, Verständlich und Robust.

Zunehmend machen auch gesetzliche Anforderungen, wie das Barrierefreiheitsgessetz (BFG) in Österreich bzw. die entsprechenden EU-Richtlinien, die Barrierefreiheit von Web-Anwendungen zur Pflicht.

Beispiele für Prüfpunkte: Sind ausreichende Farbkontraste zwischen Text und Hintergrund gegeben? Ist die gesamte Web-Anwendung per Tastatur bedienbar? Sind für alle Bilder aussagekräftige Alternativtexte hinterlegt? Werden für Videos Untertitel und gegebenenfalls Audiodeskriptionen angeboten?

Auswahl und Priorisierung der Testarten

Die Auswahl und Priorisierung der verschiedenen Testarten und -verfahren darf nicht willkürlich erfolgen, sondern muss sich stringent an den spezifischen Geschäftsrisiken und -zielen der jeweiligen Web-Anwendung orientieren. Da vollständiges Testen gemäß dem zweiten Testprinzip unmöglich ist und Ressourcen stets begrenzt sind, ist eine risikobasierte Herangehensweise entscheidend. Für eine E-Commerce-Anwendung beispielsweise sind die Performance unter hoher Last (z.B. während saisonaler Verkaufsaktionen) und die Sicherheit der Zahlungsdaten von existenzieller Bedeutung, da Fehler in diesen Bereichen direkten finanziellen Schaden und erheblichen Reputationsverlust nach sich ziehen können. Im Gegensatz dazu mag für ein internes Wissensmanagement-System die Usability und die Effektivität der Suchfunktion kritischer sein als die Bewältigung extremer Lastspitzen.

Eine weitere wichtige Erkenntnis ist, dass nicht-funktionale Anforderungen oft nur implizit im Raum stehen und aktiv durch den/die Entwickler*in in Zusammenarbeit mit den Stakeholdern explizit gemacht und in testbare Kriterien überführt werden müssen. Während funktionale Anforderungen ("Was soll das System tun?") meist klarer spezifiziert sind, bleiben nicht-funktionale Anforderungen ("Wie gut soll das System etwas tun?", z.B. bezüglich Performance, Usability, Sicherheit) häufig vage oder werden als selbstverständlich vorausgesetzt. Wenn diese nicht-funktionalen Aspekte nicht explizit definiert und systematisch getestet werden, kann eine Web-Anwendung zwar funktional korrekt sein, aber dennoch die Nutzererwartungen enttäuschen, im Betrieb versagen oder Sicherheitsrisiken bergen. Es gilt, diese impliziten Erwartungen aufzudecken (z.B. die vage Anforderung "Die Seite muss schnell laden" zu konkretisieren in "95% aller Seitenaufrufe müssen innerhalb von 2 Sekunden vollständig geladen sein"), in messbare und somit testbare Kriterien zu überführen und sicherzustellen, dass entsprechende nicht-funktionale Tests geplant und durchgeführt werden. Dies ist ein kritischer Beitrag zur Sicherstellung der Gesamtqualität und letztlich zum wirtschaftlichen Erfolg der Web-Anwendung.

Sicherheit im Fokus: SAST, DAST und DevSecOps-Praktiken

Die Sicherheit von Web-Anwendungen ist ein nicht zu vernachlässigender Aspekt der Qualitätssicherung, da diese Systeme oft direkt aus dem Internet erreichbar und somit potenziellen Angriffen ausgesetzt sind. Sicherheitslücken können schwerwiegende Folgen haben, darunter Datenverlust, finanzielle Schäden und einen massiven Reputationsverlust für das betroffene Unternehmen. Die OWASP Top 10 Liste, die regelmäßig die kritischsten Sicherheitsrisiken für Web-Anwendungen zusammenfasst, dient als wichtige Grundlage für die Planung und Durchführung von Sicherheitstests. Umfassende Sicherheitsprüfungen beinhalten typischerweise eine Kombination aus statischen und dynamischen Analyseverfahren sowie die Integration von Sicherheitspraktiken in den gesamten Entwicklungszyklus.

Static Application Security Testing (SAST): "White-Box"-Analyse des Codes

SAST ist eine "White-Box"-Testmethode, die den Quellcode, Bytecode oder die Binärdateien einer Anwendung analysiert, ohne dass die Anwendung dafür ausgeführt werden muss.142 Der Hauptvorteil von SAST liegt in der Möglichkeit der frühen Fehlererkennung direkt im Entwicklungsprozess, oft schon während des Programmierens (Shift-Left-Prinzip). So können Schwachstellen identifiziert und behoben werden, bevor der Code überhaupt in eine Testumgebung oder gar in die Produktion gelangt.

Typische Schwachstellen, die durch SAST-Tools aufgedeckt werden können, sind beispielsweise Muster, die auf SQL-Injection oder Cross-Site-Scripting (XSS) hindeuten, Pufferüberläufe, unsichere Verwendung von APIs oder fehlerhafte Implementierungen kryptographischer Verfahren. Es gibt eine Vielzahl von SAST-Werkzeugen, sowohl kommerzielle als auch Open-Source-Lösungen, die gängige Web-Technologien wie JavaScript, Java, Python, PHP und andere unterstützen. Beispiele hierfür sind SonarQube, Checkmarx, Veracode, Snyk Code oder ESLint speziell für JavaScript-Code. Für eine kontinuierliche Sicherheitsüberprüfung ist die Integration von SAST-Scans in CI/CD-Pipelines unerlässlich. Dadurch erhalten Entwickler bei jedem Code-Commit oder Build automatisiertes und schnelles Feedback zu potenziellen Sicherheitsproblemen.

Dynamic Application Security Testing (DAST): "Black-Box"-Analyse der laufenden Anwendung

Im Gegensatz zu SAST ist DAST eine "Black-Box"-Testmethode, die die Web-Anwendung von außen im laufenden Zustand testet, ohne Einblick in den Quellcode zu haben. DAST-Tools simulieren typische Angriffsvektoren und -muster, um Schwachstellen aufzudecken. Der Vorteil von DAST liegt darin, dass es Laufzeit-Schwachstellen und Konfigurationsfehler finden kann, die SAST-Tools möglicherweise übersehen, da diese den Code nicht ausführen. DAST testet die Anwendung aus der Perspektive eines potenziellen Angreifers. Typische Funde von DAST-Analysen sind erfolgreich durchgeführte Cross-Site-Scripting-Angriffe durch manipulierte Eingaben, ausnutzbare SQL-Injection-Lücken in Formularfeldern, Probleme im Session-Management oder serverseitige Fehlkonfigurationen, die von außen sichtbar sind.

Bekannte DAST-Werkzeuge sind beispielsweise der Open-Source Zed Attack Proxy (ZAP) von OWASP oder kommerzielle Tools wie Burp Suite, Invicti und Rapid7 InsightAppSec. Eine wesentliche Voraussetzung für DAST ist eine lauffähige Testumgebung, die der Produktionsumgebung möglichst nahekommt, um realistische Testergebnisse zu erzielen.

DevSecOps: Sicherheit als integraler Bestandteil des gesamten Lebenszyklus

DevSecOps repräsentiert einen kulturellen und methodischen Ansatz, der Sicherheitsaktivitäten, -werkzeuge und eine sicherheitsbewusste Kultur in den gesamten DevOps-Prozess integriert. Das Ziel ist "Security by Design" und die Anwendung von "Shift Left"- (frühzeitige Sicherheitstests) und "Shift Right"-Prinzipien (kontinuierliches Sicherheitsmonitoring im Betrieb).

Zu den Kernpraktiken von DevSecOps gehören:

• Die umfassende Automatisierung von Sicherheitstests (SAST, DAST, Software Composition Analysis/Dependency Scanning) direkt in den CI/CD-Pipelines.
• Die Absicherung der Infrastruktur durch "Infrastructure as Code" (IaC) Security-Praktiken.
• Kontinuierliches Monitoring und Logging von Sicherheitsereignissen in Test- und Produktionsumgebungen.
• Die Durchführung von Bedrohungsmodellierungen (Threat Modeling) bereits in frühen Designphasen, um potenzielle Angriffsvektoren zu identifizieren.
• Regelmäßige Sicherheitsschulungen für Entwickler, um das Bewusstsein für sichere Programmierpraktiken zu schärfen.
• Die Förderung einer engen Kollaboration und Kommunikation zwischen Entwicklungs-, Operations- und Sicherheitsteams, um Silos aufzubrechen. Das übergeordnete Ziel von DevSecOps ist die schnellere und gleichzeitig sicherere Auslieferung von Software durch die frühzeitige Erkennung und Behebung von Schwachstellen sowie die Etablierung einer nachhaltigen Sicherheitskultur im gesamten Unternehmen.

Es ist wichtig zu verstehen, dass SAST und DAST keine konkurrierenden, sondern vielmehr komplementäre Ansätze darstellen, die im Rahmen einer umfassenden DevSecOps-Strategie optimal zusammenwirken. SAST analysiert den Code "von innen" und kann potenzielle Schwachstellen sehr früh im Entwicklungsprozess aufdecken, oft direkt in der Entwicklungsumgebung (IDE) oder als Teil der Continuous Integration Pipeline. Da SAST sprachabhängig ist, kann es tendenziell eine höhere Anzahl an False Positives generieren, also Warnungen, die sich bei genauerer Betrachtung nicht als echte Schwachstellen herausstellen. DAST hingegen testet die laufende Anwendung "von außen", ist sprachunabhängig und findet Laufzeitfehler sowie Konfigurationsprobleme, benötigt aber eine lauffähige Anwendungsumgebung. SAST kann somit Fehler aufdecken, bevor eine Anwendung überhaupt lauffähig ist, während DAST erst dann zum Einsatz kommt. Eine effektive Sicherheitsstrategie, wie sie DevSecOps anstrebt, nutzt die Stärken beider Ansätze: SAST liefert frühes Feedback an die Entwickler, DAST prüft die Anwendung unter realitätsnahen Bedingungen in Staging- oder sogar (kontrollierten) Produktionsumgebungen. Für Studierende der Wirtschaftsinformatik ist das Verständnis entscheidend, dass nicht die Wahl eines einzelnen Tools, sondern die intelligente Kombination und nahtlose Integration verschiedener Sicherheitstesting-Ansätze in den gesamten Softwareentwicklungslebenszyklus den größten Nutzen für die Sicherheit von Web-Anwendungen stiftet.

Die bloße Einführung von SAST/DAST-Tools und die Deklaration von DevSecOps führen jedoch nicht automatisch zu mehr Sicherheit. Die Effektivität dieser Maßnahmen hängt maßgeblich von der gelebten Unternehmenskultur und der Bereitschaft zur Kollaboration zwischen allen beteiligten Teams ab. DevSecOps betont die gemeinsame Verantwortung für Sicherheit – "Security is everyone's job". Wenn Entwickler die Ergebnisse von Sicherheitsscans ignorieren, weil sie beispielsweise durch eine hohe Rate an False Positives frustriert sind, oder wenn Sicherheitsteams primär als Bremser und Blockierer neuer Entwicklungen wahrgenommen werden, bleiben die erhofften Verbesserungen aus. Eine erfolgreiche Implementierung erfordert daher begleitende Maßnahmen wie zielgerichtete Schulungen, klare und nachvollziehbare Prozesse für den Umgang mit identifizierten Schwachstellen (z.B. Priorisierung, Triage, Verantwortlichkeiten) und eine Kultur, in der Sicherheit als gemeinsames Ziel und integraler Bestandteil von Qualität verstanden und gelebt wird. 

Testautomatisierung und Testdatenmanagement

Die Testautomatisierung und ein sorgfältiges Testdatenmanagement sind entscheidende Säulen für eine effiziente und effektive Qualitätssicherung von Web-Anwendungen, insbesondere in agilen Umfeldern mit kurzen Release-Zyklen.

Die Testautomatisierungspyramide: Eine Strategie für Testautomatisierung

Das Konzept der Testautomatisierungspyramide, ursprünglich von Mike Cohn vorgestellt und durch Martin Fowler popularisiert, bietet eine Leitlinie für die Verteilung von Testautomatisierungsaufwänden auf verschiedenen Ebenen.

Test Pyramid

Die Testautomatisierungspyramide ist ein Modell, dessen Implementierung jedoch stark von der Testbarkeit der zugrundeliegenden Anwendungsarchitektur abhängt. Die Pyramide empfiehlt eine große Anzahl von Unit- und API-Tests und nur wenige UI-Tests. Unit-Tests erfordern gut isolierbare Code-Module, während API-Tests klar definierte und stabile Schnittstellen voraussetzen. Wenn eine Web-Anwendung beispielsweise monolithisch aufgebaut ist, mit stark verflochtenen Komponenten und ohne klar getrennte API-Schichten (im Gegensatz zu z.B. Microservice-Architekturen), wird es schwierig, Tests auf den unteren, schnellen Ebenen der Pyramide effektiv zu implementieren. Dies kann dazu führen, dass Teams gezwungen sind, sich stärker auf die langsameren und instabileren UI-Tests zu verlassen, was dem eigentlichen Ziel der Pyramide widerspricht und oft als Anti-Pattern ("Eistüte" oder "Testkrabbe") bezeichnet wird.

An der Basis der Pyramide befinden sich Unit-Tests (Komponententests). Dies sind zahlreiche, sehr schnell auszuführende und isolierte Tests, die einzelne, kleine Code-Einheiten wie Funktionen, Methoden oder Klassen überprüfen. Sie werden in der Regel von den Entwicklern selbst geschrieben und bieten ein sehr schnelles Feedback über die Korrektheit des Codes auf niedrigster Ebene.163 Ein Beispiel für eine Web-Anwendung in JavaScript wäre das Testen einer Funktion, die Benutzereingaben in einem Formular validiert 163, oder einer einzelnen UI-Komponente, die für die Darstellung eines bestimmten Teils der Benutzeroberfläche zuständig ist.

In der mittleren Schicht der Pyramide sind API-Tests, Integrations- oder Service-Tests angesiedelt. Es gibt weniger davon als Unit-Tests, und sie prüfen das korrekte Zusammenspiel verschiedener Komponenten oder Dienste über deren definierte Schnittstellen (APIs), typischerweise ohne die grafische Benutzeroberfläche (UI) einzubeziehen. Diese Tests sind schneller und stabiler als UI-Tests.167 Für eine E-Commerce-Web-Anwendung könnten dies Tests sein, die API-Endpunkte für den Produktabruf, die Aktualisierung des Warenkorbs oder die Aufgabe einer Bestellung verifizieren. Auch die Simulation der Interaktion zwischen einem Frontend und verschiedenen Backend-Microservices fällt in diese Kategorie.

An der Spitze der Pyramide stehen die UI-Tests (End-to-End-Tests). Davon sollte es am wenigsten geben, da sie tendenziell langsam in der Ausführung, aufwendig in der Erstellung und Wartung sowie anfälliger für Instabilitäten (sogenannte "flaky tests") sind. UI-Tests simulieren komplette Benutzer-Workflows über die grafische Benutzeroberfläche und prüfen das integrierte System aus der Endbenutzerperspektive. Ein Beispiel für eine E-Commerce-Anwendung wäre das Durchtesten des gesamten Kaufprozesses: von der Produktsuche über das Hinzufügen zum Warenkorb, die Eingabe von Adress- und Zahlungsdaten bis hin zur Anzeige der Bestellbestätigungsseite. Der praktische Nutzen dieser Pyramidenstrategie liegt im Fokus auf einer breiten Basis von schnellen, kostengünstigen und stabilen Unit- und API-Tests, die ein schnelles Feedback ermöglichen, ergänzt durch eine gezielte, geringere Anzahl von umfassenderen UI-Tests, um die wichtigsten End-to-End-Szenarien abzusichern.

Vorteile, Nachteile und ROI der Testautomatisierung für Web-Anwendungen:

Die Testautomatisierung bietet verschiedene Vorteile: schnellere Testdurchführung (insbesondere bei Regressionstests), Konsistenz und Wiederholbarkeit der Tests, potenziell höhere Testabdeckung, früheres Feedback an die Entwicklung, Entlastung manueller Tester für komplexere Aufgaben wie exploratives Testen oder anspruchsvolle Usability-Bewertungen und die Ermöglichung von Continuous Integration und Continuous Delivery (CI/CD).

Dem stehen jedoch auch Nachteile gegenüber: hohe Initialkosten für die Auswahl und Implementierung von Tools, die Entwicklung von Testautomatisierungs-Frameworks und die Erstellung der initialen Testskripte. Der Wartungsaufwand für Testskripte, besonders bei häufigen Änderungen an der UI, kann erheblich sein. Zudem erfordert Testautomatisierung spezialisierte Kenntnisse und Fähigkeiten im Team, und nicht alle Testarten sind sinnvoll oder wirtschaftlich automatisierbar (z.B. explorative Tests, bestimmte Aspekte der Usability oder Tests, die stark von menschlicher Intuition abhängen).

Der Return on Investment (ROI) der Testautomatisierung ist eine wichtige Kennzahl, um die Wirtschaftlichkeit von Automatisierungsbemühungen zu bewerten. Die Grundformel lautet: ROI=Kosten der Automatisierung (Einsparungen durch Automatisierung−Kosten der Automatisierung)​⋅100. Die Einsparungen ergeben sich primär aus reduzierter manueller Testzeit, schnellerer Fehlererkennung (was zu geringeren Behebungskosten führt) und potenziell schnelleren Release-Zyklen. Die Kosten umfassen Tool-Lizenzen, Infrastrukturaufwendungen sowie die Entwicklungs- und Wartungszeit für die automatisierten Testskripte.

Fallstudien und Beispiele, insbesondere im E-Commerce-Bereich, zeigen, dass die Automatisierung von umfangreichen Regressionstest-Suiten für kritische Prozesse wie den Checkout bei häufigen Releases erhebliche manuelle Aufwände einsparen und gleichzeitig sicherstellen kann, dass die Kernfunktionalitäten stabil bleiben und keine neuen Fehler eingeschleppt werden.

Auswahl von Testautomatisierungswerkzeugen (UI und API)

Die Auswahl geeigneter Werkzeuge ist entscheidend für den Erfolg der Testautomatisierung. Wichtige Kriterien sind: die Unterstützung der im Projekt verwendeten Technologien (Programmiersprachen, Browser, Frameworks), die vorhandenen Skills im Team (code-basierte Tools erfordern Programmierkenntnisse, während Low-Code/No-Code-Plattformen auch für Fachanwender zugänglicher sein können), das verfügbare Budget (Open-Source-Lösungen versus kommerzielle Produkte), die Skalierbarkeit der Lösung für wachsende Testumfänge, die Integrationsfähigkeit in bestehende CI/CD-Pipelines und Testmanagement-Systeme, aussagekräftige Reporting-Funktionen sowie die Verfügbarkeit von Community-Support und Dokumentation.

Beispiele für UI-Testautomatisierungstools:

• Selenium: Ein weit verbreitetes Open-Source-Framework, das eine breite Palette von Programmiersprachen (Java, Python, C#, JavaScript etc.) und Browsern unterstützt. Es bietet hohe Flexibilität und verfügt über eine große, aktive Community.
• Cypress: Ein modernes, JavaScript-basiertes End-to-End-Testing-Framework, das für seine Entwicklerfreundlichkeit, schnelle Ausführung und gute Debugging-Möglichkeiten bekannt ist.
• Playwright: Ein von Microsoft entwickeltes Tool, das ebenfalls mehrere Programmiersprachen unterstützt und durch eine moderne Architektur sowie gute Performance bei Cross-Browser-Tests überzeugt.

Beispiele für API-Testautomatisierungstools:

• Postman: Ein populäres Tool mit einer grafischen Benutzeroberfläche, das sich gut für manuelle und explorative API-Tests sowie für die einfache Automatisierung von API-Testabläufen eignet.
• REST Assured: Eine Java-Bibliothek, die sich besonders gut für die Integration von API-Tests in Java-basierte Projekte eignet und eine hohe Flexibilität für komplexe Testszenarien bietet.

Moderne Ansätze im Testing: Der Einfluss von Künstlicher Intelligenz (KI)

Künstliche Intelligenz und Machine Learning (ML) gewinnen auch im Bereich Softwaretests zunehmend an Bedeutung und bieten neue Möglichkeiten zur Effizienzsteigerung und Qualitätsverbesserung:

KI-gestützte Testfallgenerierung: ML-Modelle können dazu verwendet werden, Anforderungen, User Stories oder bestehenden Code zu analysieren, um daraus automatisch Testfälle zu generieren oder Vorschläge für Testfälle zu optimieren.

Visuelle Tests mit KI: KI-basierte Tools können automatisch visuelle Abweichungen in der Benutzeroberfläche erkennen (z.B. Layoutverschiebungen, Farbänderungen, fehlende Elemente), die von rein funktionalen Tests oft nicht erfasst werden.

Self-Healing Automation (Selbstreparierende Testautomatisierung): KI-Algorithmen sind in der Lage, Änderungen in der UI einer Web-Anwendung (z.B. geänderte IDs oder XPath-Lokalisierer von Elementen) während der Testausführung zu erkennen und die Testskripte automatisch anzupassen. Dies kann den Wartungsaufwand für automatisierte Tests signifikant reduzieren.

Testoptimierung durch ML: Durch die Analyse von historischen Testausführungsprotokollen und Fehlerdaten können ML-Modelle dabei helfen, redundante Testfälle zu identifizieren, die Testausführung zu priorisieren (z.B. Tests für fehleranfällige Bereiche zuerst ausführen) oder Vorhersagen über die Fehlerwahrscheinlichkeit in bestimmten Modulen zu treffen.

Testdatenmanagement

Qualitativ hochwertige und aussagekräftige Testdaten sind eine essenzielle Voraussetzung für effektive Tests. Die Verwendung von Echtdaten aus Produktivsystemen ist jedoch aus Datenschutzgründen, insbesondere im Hinblick auf die Datenschutz-Grundverordnung (DSGVO/GDPR), oft problematisch oder schlichtweg verboten.209

Folgende Techniken ermöglichen ein DSGVO-konformes Testdatenmanagement:

Anonymisierung/Pseudonymisierung: Personenbezogene Daten werden so entfernt oder verfremdet, dass kein direkter Rückschluss auf einzelne Individuen mehr möglich ist. Es ist jedoch zu beachten, dass eine echte, unwiderrufliche Anonymisierung schwer zu erreichen ist und pseudonymisierte Daten unter Umständen weiterhin unter den Anwendungsbereich der DSGVO fallen können.

Generierung synthetischer Testdaten: Hierbei werden künstliche, aber realistisch wirkende Datensätze erstellt. Diese Daten spiegeln die statistischen Eigenschaften und die Struktur von Echtdaten wider, enthalten aber keine realen Personenbezüge und sind somit datenschutzrechtlich unbedenklich.