1.1 Was ist Testen?
Softwaresysteme sind Teil unseres täglichen Lebens. Software, die nicht ordnungsgemäß funktioniert, kann zu vielen Problemen führen – von Geld-, Zeit- oder Ansehensverlust bis hin zu Verletzungen oder Tod in Extremfällen. Softwaretests bewerten die Qualität der Software und helfen, das Risiko einer Fehlerwirkung im Betrieb zu verringern.
Testen besteht aus einer Reihe von Aktivitäten zur Entdeckung von Fehlerzuständen und zur Bewertung der Qualität von Arbeitsergebnissen. Ein weit verbreitetes Missverständnis ist, dass Testen nur aus dem Ausführen von Tests besteht. Tatsächlich umfasst Testen viele weitere Aktivitäten und muss auf den Softwareentwicklungslebenszyklus (SDLC) abgestimmt sein.
Testen kann dynamisch (Software wird ausgeführt) oder statisch (Software wird nicht ausgeführt, z.B. Reviews) sein. Testen ist nicht nur eine technische Aktivität – es muss auch richtig geplant, verwaltet, geschätzt, überwacht und gesteuert werden.
Testziele
Typische Testziele sind:
- Evaluieren von Arbeitsergebnissen wie Anforderungen, User-Storys, Entwürfe und Code
- Auslösen von Fehlerwirkungen und Finden von Fehlerzuständen
- Sicherstellen der erforderlichen Überdeckung eines Testobjekts
- Verringern des Risikos einer unzureichenden Softwarequalität
- Verifizieren, ob spezifizierte Anforderungen erfüllt wurden
- Verifizieren, ob vertragliche, rechtliche und regulatorische Anforderungen erfüllt sind
- Bereitstellen von Informationen für Stakeholder zur Entscheidungsfindung
- Aufbauen von Vertrauen in die Qualität des Testobjekts
- Validieren, ob das Testobjekt vollständig ist und wie erwartet funktioniert
Die Testziele können je nach Kontext variieren – abhängig vom zu testenden Arbeitsergebnis, der Teststufe, Risiken, dem SDLC und geschäftlichen Faktoren.
Testen und Debugging
Testen und Debugging sind getrennte Aktivitäten. Testen kann Fehlerwirkungen auslösen oder direkt Fehlerzustände finden. Debugging hingegen umfasst:
- Reproduzieren einer Fehlerwirkung
- Diagnose (den Fehlerzustand finden)
- Behebung des Fehlerzustands
Nach dem Debugging folgen Fehlernachtests (prüfen, ob das Problem behoben wurde) und Regressionstests (prüfen, ob die Korrekturen andere Teile des Systems beeinträchtigt haben).
1.2 Warum ist Testen notwendig?
Der Beitrag des Testens zum Erfolg
Testen ist ein kosteneffizientes Mittel zur Erkennung von Fehlerzuständen. Diese können dann beseitigt werden (durch Debugging), sodass Testen indirekt zu einer höheren Qualität der Testobjekte beiträgt.
Testen bietet:
- Ein Mittel zur direkten Bewertung der Qualität in verschiedenen SDLC-Phasen
- Messgrößen für Projektmanagement-Entscheidungen (z.B. Freigabeentscheidungen)
- Eine indirekte Darstellung des Entwicklungsprojekts für Benutzer
- Erfüllung vertraglicher, gesetzlicher oder regulatorischer Anforderungen
Testen und Qualitätssicherung
Obwohl die Begriffe oft synonym verwendet werden, sind Testen und Qualitätssicherung (QS) nicht dasselbe:
| Aspekt | Testen | Qualitätssicherung (QS) |
|---|---|---|
| Ausrichtung | Produktorientiert, korrigierend | Prozessorientiert, präventiv |
| Fokus | Aktivitäten zur Erreichung eines angemessenen Qualitätsniveaus | Implementierung und Verbesserung von Prozessen |
| Rolle | Form der Qualitätssteuerung | Annahme: guter Prozess → gutes Produkt |
| Verantwortung | Primär Testteam | Alle Projektbeteiligten |
Testergebnisse werden in beiden Bereichen verwendet: beim Testen zur Behebung von Fehlerzuständen, in der QS als Rückmeldung über die Qualität der Entwicklungs- und Testprozesse.
Fehlhandlungen, Fehlerzustände, Fehlerwirkungen und Grundursachen
Menschen begehen Fehlhandlungen (Irrtümer), die zu Fehlerzuständen (Defekten) führen, was wiederum zu Fehlerwirkungen führen kann.
Gründe für Fehlhandlungen:
- Zeitdruck
- Komplexität von Arbeitsergebnissen, Prozessen oder Interaktionen
- Erschöpfung oder unzureichende Schulung
Eine Grundursache (root cause) ist ein wesentlicher Grund für das Auftreten eines Problems. Durch Grundursachenanalyse können ähnliche Fehlerwirkungen oder Fehlerzustände in Zukunft verhindert oder reduziert werden.
1.3 Grundsätze des Testens
Im Laufe der Jahre wurden sieben Grundsätze entwickelt, die allgemeine Richtlinien für alle Tests bieten:
Testen kann zeigen, dass Fehlerzustände vorhanden sind, kann aber nicht beweisen, dass keine existieren. Selbst wenn keine Fehlerzustände gefunden werden, kann Testen nicht die Korrektheit des Testobjekts beweisen.
Es ist nicht möglich, alles zu testen (außer in trivialen Fällen). Stattdessen sollten Testverfahren, Priorisierung und risikobasiertes Testen angewendet werden, um den Testaufwand gezielt einzusetzen.
Fehlerzustände, die früh im Prozess beseitigt werden, verursachen keine weiteren Fehlerzustände in abgeleiteten Arbeitsergebnissen. Die Qualitätskosten werden gesenkt, da später im SDLC weniger Fehlerwirkungen auftreten. Sowohl statische als auch dynamische Tests sollten so früh wie möglich beginnen.
Eine kleine Anzahl von Komponenten enthält meist die meisten entdeckten Fehlerzustände oder ist für die meisten Fehlerwirkungen im Betrieb verantwortlich (Pareto-Prinzip). Vorausgesagte und tatsächlich beobachtete Anhäufungen sind ein wichtiger Beitrag für risikobasiertes Testen.
Wenn dieselben Tests viele Male wiederholt werden, werden sie bei der Erkennung neuer Fehlerzustände zunehmend ineffektiv. Bestehende Tests müssen möglicherweise modifiziert und neue Tests geschrieben werden. In einigen Fällen (z.B. automatisierte Regressionstests) kann die Wiederholung jedoch positiv sein.
Es gibt keinen universell anwendbaren Ansatz für das Testen. Testen wird in verschiedenen Kontexten unterschiedlich praktiziert.
Es ist ein Irrtum zu erwarten, dass das Verifizieren von Software den Erfolg eines Systems sicherstellt. Gründliches Testen aller Anforderungen und Beheben aller Fehlerzustände könnte immer noch ein System hervorbringen, das die Bedürfnisse der Benutzer nicht erfüllt. Neben der Verifizierung sollte auch eine Validierung durchgeführt werden.
1.4 Testaktivitäten, Testmittel und Rollen des Testens
Auf einem hohen Abstraktionsniveau gibt es Gruppen von Testaktivitäten, die einen Testprozess bilden. Welche Testaktivitäten durchgeführt werden, wie sie durchgeführt werden und wann sie stattfinden, wird normalerweise im Rahmen der Testplanung entschieden.
Testaktivitäten und -aufgaben
Ein Testprozess besteht aus folgenden Hauptgruppen von Aktivitäten. Obwohl sie einer logischen Abfolge zu folgen scheinen, werden sie oft iterativ oder parallel durchgeführt:
Testplanung
Testziele definieren und eine Testvorgehensweise auswählen, mit der die Testziele innerhalb der Randbedingungen am besten erreicht werden können.
Testüberwachung und Teststeuerung
Laufende Überprüfung aller Testaktivitäten, Vergleich des Fortschritts mit dem Plan und Ergreifen von Korrekturmaßnahmen zur Erreichung der Testziele.
Testanalyse
Analyse der Testbasis, um testbare Merkmale zu identifizieren. Testbedingungen werden bestimmt und priorisiert. Beantwortet die Frage: „Was soll getestet werden?"
Testentwurf
Ausarbeitung der Testbedingungen zu Testfällen und anderen Testmitteln. Definition von Anforderungen an Testdaten, Entwurf der Testumgebung. Beantwortet die Frage: „Wie soll getestet werden?"
Testrealisierung
Erstellung oder Beschaffung der für die Testdurchführung erforderlichen Testmittel (z.B. Testdaten). Testfälle werden in Testabläufen organisiert, Testskripte erstellt, Testumgebung aufgebaut.
Testdurchführung
Ausführung der Tests gemäß Testausführungsplan (manuell oder automatisiert). Istergebnisse werden mit erwarteten Ergebnissen verglichen. Abweichungen werden analysiert und berichtet.
Testabschluss
Findet zu Projektmeilensteinen statt. Änderungsanträge für nicht behobene Fehlerzustände erstellen, Testmittel archivieren, Lessons Learned ermitteln, Testabschlussbericht erstellen.
Testprozess im Kontext
Testen wird nicht isoliert durchgeführt. Die Art und Weise, wie Testen durchgeführt wird, hängt von zahlreichen Kontextfaktoren ab:
- Stakeholder: Bedürfnisse, Erwartungen, Anforderungen, Bereitschaft zur Zusammenarbeit
- Teammitglieder: Kompetenz, Wissen, Erfahrung, Verfügbarkeit, Schulungsbedarf
- Unternehmensbereich: Kritikalität des Testobjekts, Risiken, Marktbedürfnisse, gesetzliche Vorschriften
- Technische Faktoren: Art der Software, Produktarchitektur, verwendete Technologie
- Projektbedingte Randbedingungen: Umfang, Zeit, Budget, Ressourcen
- Organisatorische Faktoren: Organisationsstruktur, bestehende Richtlinien, angewandte Praktiken
- SDLC: Technologische Praktiken, Entwicklungsmethoden
- Werkzeuge: Verfügbarkeit, Gebrauchstauglichkeit, Konformität
Diese Faktoren wirken sich auf Teststrategie, verwendete Testverfahren, Grad der Testautomatisierung, geforderte Überdeckung, Detaillierungsgrad der Testmittel und Testberichterstattung aus.
Testmittel
Verfolgbarkeit zwischen der Testbasis und den Testmitteln
Für eine effektive Testüberwachung und Teststeuerung ist es wichtig, eine Verfolgbarkeit (Traceability) herzustellen und zu pflegen zwischen:
- Bestandteilen der Testbasis
- Mit diesen Bestandteilen verbundenen Testmitteln (z.B. Testbedingungen, Risiken, Testfälle)
- Testergebnissen
- Fehlerzuständen
Vorteile guter Verfolgbarkeit:
- Bewertung der Überdeckung (z.B. welche Anforderungen durch Testfälle überdeckt sind)
- Ermittlung der Auswirkungen von Änderungen
- Erleichterung von Audits
- Erfüllung von IT-Governance-Kriterien
- Verständlichere Testfortschritts- und Testabschlussberichte
- Vermittlung technischer Aspekte des Testens an Stakeholder
Rollen des Testens
Zwei Hauptrollen werden unterschieden:
| Aspekt | Rolle des Testmanagements | Rolle des Testens |
|---|---|---|
| Verantwortung | Gesamtverantwortung für Testprozess, Testteam und Leitung der Testaktivitäten | Gesamtverantwortung für den operativen Aspekt des Testens |
| Fokus | Testplanung, Testüberwachung, Teststeuerung, Testabschluss | Testanalyse, Testentwurf, Testrealisierung, Testdurchführung |
| Ausführung | Kann von Teamleiter, Testmanager, Entwicklungsleiter ausgeübt werden | Tester, die Tests entwerfen und durchführen |
Diese Rollen können von verschiedenen Personen zu verschiedenen Zeiten übernommen werden. Es ist auch möglich, dass eine Person beide Rollen gleichzeitig übernimmt.
1.5 Wesentliche Kompetenzen und bewährte Praktiken beim Testen
Kompetenz ist die Fähigkeit, etwas gut zu machen, die sich aus Wissen, Übung und Eignung ergibt. Gute Tester sollten effektive Teamplayer sein und in der Lage sein, Tests mit verschiedenen Graden an Unabhängigkeit durchzuführen.
Allgemeine Kompetenzen, die für das Testen erforderlich sind
Die folgenden Kompetenzen sind zwar allgemeiner Art, aber für Tester besonders wichtig:
- Testwissen: Zur Steigerung der Effektivität (z.B. durch Einsatz von Testverfahren)
- Gründlichkeit, Sorgfalt, Neugier, Detailgenauigkeit, methodisches Vorgehen: Um Fehlerzustände zu erkennen, insbesondere schwer zu findende
- Gute Kommunikationsfähigkeit, aktives Zuhören, Teamfähigkeit: Um mit Stakeholdern effektiv zu interagieren, Informationen weiterzugeben und Fehlerzustände zu berichten
- Analytisches Denken, kritisches Denken, Kreativität: Zur Steigerung der Effektivität des Testens
- Technische Kenntnisse: Um die Effizienz zu steigern (z.B. durch Einsatz geeigneter Testwerkzeuge)
- Wissen in der Anwendungsdomäne: Um Endanwender zu verstehen und mit ihnen kommunizieren zu können
Whole-Team-Ansatz (Whole Team Approach)
Der Whole-Team-Ansatz – eine aus Extreme Programming stammende Praxis – baut auf der Teamfähigkeit auf:
- Jedes Teammitglied mit den erforderlichen Kompetenzen kann jede Aufgabe ausführen
- Jeder ist für die Qualität verantwortlich
- Teammitglieder teilen sich einen gemeinsamen Arbeitsbereich (physisch oder virtuell)
- Fördert Kommunikation und Zusammenarbeit innerhalb des Teams
- Schafft Synergien durch Einsatz verschiedener Kompetenzen
Tester arbeiten eng mit anderen Teammitgliedern zusammen:
- Mit Fachbereichsvertretern zur Unterstützung bei der Erstellung geeigneter Abnahmetests
- Mit Entwicklern zur Abstimmung der Teststrategie und Testautomatisierung
- Weitergabe von Testwissen an andere Teammitglieder
Unabhängigkeit des Testens
Ein gewisser Grad an Unabhängigkeit macht den Tester effektiver bei der Fehlerfindung, da sich die Voreingenommenheit zwischen Autor und Tester unterscheidet. Unabhängigkeit ist jedoch kein Ersatz für Nähe zum System – Entwickler können viele Fehlerzustände in ihrem eigenen Code effizient finden.
Grade der Unabhängigkeit (aufsteigend):
- Autor testet eigenes Arbeitsergebnis (keine Unabhängigkeit)
- Kollegen aus demselben Team testen (etwas Unabhängigkeit)
- Tester außerhalb des Teams, aber innerhalb der Organisation (hohe Unabhängigkeit)
- Tester außerhalb der Organisation (sehr hohe Unabhängigkeit)
Bei den meisten Projekten ist es am besten, das Testen mit mehreren Unabhängigkeitsstufen durchzuführen.
| Vorteile | Nachteile |
|---|---|
|
|