Software testen und dokumentieren

Software testen und dokumentieren – kurz erklärt

• Testen & Dokumentieren gehören zum Alltag der Softwareentwicklung.

• Sie sind genauso wichtig wie Programmieren.

• Oft wird Testen & Dokumentation unterschätzt, obwohl sie für Weiterentwicklung sehr wichtig sind.

Warum früh testen?

• Früh testen & dokumentieren spart Kosten.

• Fehler früh entdecken = billiger zu beheben.

Was passiert bei späten Fehlern?

• In der Entwicklungsphase sind Fehler leicht zu korrigieren.

• Im Live-Betrieb ist die Korrektur aufwendig und teuer.

• mangelhafter nicht vorhandener Testprozess

• Gleiche gilt für Dokumentation

  • Je früher man anfängt desto präziser fällt diese aus

  
  

• Tests sind nur Stichproben, keine Garantie für Fehlerfreiheit

• Test zeigen nur, ob bestimmte Testfälle funktionieren

• Testen ist keine einzelne Phase, sondern durchzieht alle Phasen der Softwareentwicklung

• Wichtige Maßnahme für kontinuierliche Qualitätssicherung

• 
  

  Lastenheft	Pflichtenheft
  Vom Kunden geschrieben	Vom Auftragnehmer geschrieben
  Was soll gemacht werden und wofür?	Wie soll es umgesetzt werd nauf basis vom Lastenheft?
  Anforderungen, Ziele, Wünsche	Technische Lösung, Umsetzungsschritte
  „Ich will eine Suchfunktion“	„Wir bauen ein Suchfeld mit Kategorien“

• Du solltest ein Beispiel im Kopf haben wie:

  • Lastenheft: Die App soll Bücher ausleihen können

  • Pflichtenheft: Es gibt eine Datenbank, Eingabemaske, Statusfelder wie „ausleihbar“, „reserviert“

• Befragungstechniken:

  • Interviews, Fragebögen

  • Direkte Kommunikation mit Menschen

  • Was?:

    • Interviews (einzelne Personen)

    • Fragebögen (schriftlich, mehrere Personen)

    Ziel:

    • Herausfinden, was die Nutzer wollen oder brauchen

    
    

• Beobachtungstechniken:

  • Feldbeobachtung, Apprenticing

  • Man schaut Menschen bei der Arbeit zu

  • Was?:

    • Feldbeobachtung = still mitlaufen und beobachten

    • Apprenticing = „in die Lehre gehen“ = selbst mitarbeiten, um zu verstehen

  • Beispiel:

    • Du beobachtest, wie jemand in der Bibliothek Bücher ausleiht, um herauszufinden, wo Probleme auftreten

  
  

• Vergangenheitsorientierte Techniken:

  • Wenn man nichts mehr hat

  • Was:

    • Man schaut sich z. B. alte Protokolle, Tickets, Dokumentationen an

  • Beispiel:

    • „Wie lief der Ausleihprozess vor Corona?“ – Du schaust dir die alten Abläufe an, weil 

    
    

• Simulationstechniken: Simulation, Animation, Prototyping:

  • Die mögliche Lösung als Prototyp modellieren

  • Du stellst eine vereinfachte Version der Software, Website oder App dar,

    ohne echten Code, aber mit dem Ziel, sie dem Nutzer zu zeigen

  • und so Feedback zu sammeln, Anforderungen zu prüfen oder Fehler früh zu erkennen.

    
    

• Kreativitätstechniken:

  • Ideen sammeln – gemeinsam und ohne Bewertung

  • Was?

    • Brainstorming

    • 6-3-5-Methode (6 Leute, 3 Ideen, 5 Minuten)

    • Umkehrmethode („Was müsste man tun, damit es richtig schiefläuft?“)

    Ziel:

    • Viele Ideen für Lösungen oder Probleme finden

    
    

• Vorbereitungsphase

  Ergebnis: Projektskizze, Team, Projektrahmen, Informationswege

• Definitionsphase

  Ergebnis: Lösungskonzept, Projektziele, Projektvertrag

• Planungsphase

  Ergebnis: Projektplan

• Realisierungsphase

  Ergebnis: Projektergebnis (Umsetzung)

• Abschlussphase

  Ergebnis: Abnahmen, Dokumentation, Abschlussunterlagen

• Kunde gibt Stories (kurze Beschreibungen) vor

• Programmierer arbeiten immer paarweise am Rechner

• Tests werden vor dem Code geschrieben (Test First)

• Tägliche Builds und Tests

• Enge Zusammenarbeit im Team + mit dem Kunden

• Feste Arbeitszeiten, hohe Energie

  
  

  
  

Phasen:

1. Systemanforderungen <- Abnahmetest/Valedirungstest

2. Systementwurf <- Systemtest

3. Systemarchitektur <- intigrationstest

4. Komponentendesign <- Komponententest

5. Implementierung / Codierung <- Unitest

Typische Tests:

• Stresstest, Langzeittest

• Eingabevalidierung

• Beta-Version

• Test schreiben (vor dem Code!)

  • Man schreibt zuerst einen Test, der absichtlich fehlschlägt

  • Grundprinzip: Test vor Code

• Code schreiben

  • Nur so viel Code schreiben, dass der Test gerade so bestanden wird

  • Einfachste mögliche Lösung

• Refaktorisieren

  • Danach wird der Code aufgeräumt und verbessert

  • Struktur klarer machen, ohne das Verhalten zu verändern

  
  

• Ziel:

  • Mann will testen ob die Software richtig funktioniert

  • mit möglichst wenig Zeit- und Personalaufwand.

• Gewonnene Erkenntnisse

  • Werden verwendet um Fehler zu reduzieren oder nicht funktionelle Qualität nachträglich zu verbessern

• Testen wir in den meisten fällen auf funktioneller Ebene beschränkt

  • Was soll die Software tun

  
  

• Fehlerklassen definieren, Schwere bewerten

• Test- und Abnahmekriterien festlegen

  
  

• Testumfang, -objekte, Prioritäten bestimmen

• Testarten und -stufen wählen

• Testdaten und -umgebung festlegen

  
  

• Ressourcen & Team planen

  
  

• Test steuern und überwachen (Laufende Kontrolle und Anpassung des Testvorgangs)

• Testprozess dokumentieren (alles was man beim Testen macht wird Dokkumentiert)

• Testplanung:

  • früh wie möglich umgestzt werden

  • Ergebnis:

    • Teststrategie (Wie wird getestet?)

    • Testziele (Was soll erreicht werden?)

    • Testbeginn/-ende (Zeitplanung)

    • Hilfsmittel/Werkzeuge (z. B. Programme, Tools)

• Testentwurf:

  • Konkrete Testfälle werden erstellt

  • Testabläufe festgelegt

  • Entscheidet bewusst, welche Tests man manuell oder automatisch ausführt

• Testvorbereitung:

  • Testszenarien festlegen

  • Testgeräte, Tools und Team bereitstellen

  • Testfälle, Testumgebung auswählen

  • Testdaten + Vorlagen vorbereiten

• Testdurchführung:

  • Dynamisch = Programm wird ausgeführt

  • Statisch = analystische Test vollzogenb

  
  

• Testauswertung:

  • Auswertung der Testergebnisse und vergleich mit den erwarteten Testergebnisse

  • Entscheidungüber bestanden oder nicht bestanden

• Testabschluss:

  • Abschluss der Dokumentation der Testergebnisse

• Stastische Testverfahren:

  • Man führt das Programm nicht aus stattdessen prüft man den Code

  • Inspektion

    • (Gruppe schaut sich gemeinsam den Code/Text an und sucht Fehler)

  • Review

    • Eine oder mehrere Personen lesen etwas durch (z. B. Pflichtenheft, Code, Doku)

• Dynamische Testverfahren:

  •  Mit Ausführung des Programms

  • Man beobachtet, wie es sich wirklich verhält

  • Beispiel:

    • Whitbox-Test

      • Du testest das Programm, und du kennst den Quellcode

    • Blackbox-Test

      • Du testest das Programm ohne den Quellcode zu kennen

      
      

• Test ohne Ausführen der Software auf Rechner

• Prüfobjekte meistens:

  • Quellcode und Entwicklungsdokumente

  • Aber auch nich technische Dokummente wie z.B Anforderungsspezifikation, Benutzerhandbuch

    
    

• Teil des Qualitätsmanagements

  
  

• Methoden: Sie werden in allen Phasen einer Entwicklung angewendet

  • Inspektion→ Ein Team prüft den Code oder ein Dokument nach festen Regeln→ Sehr gründlich – entdeckt viele Fehler (siehe: „50–75 %“)

  • Review-> Weniger Aufwendig als die Inspektion → 60-75% aller Fehler werden entdeckt

  • Walkthrough-> Unstrukturierte Vorgehensweise Entwickler präsentiert das Programm und der Gutachter stellt spontan Fragen

  • Audit -> Struckturierter als ein Walkthrough. Der Gutachter stellt nach einem festgelegten Prüfkatalog Fragen

  • Statische Code-Analyse Geprüft wird:

    • Architektur

    • Einsatz der Programmiersprache

    • Einhalten von Namenskonventionen

• Vorteile:

  • Frühe Fehlererkennung

  • Fehlerzustände werden direkt aufgedeckt

  • Verringert teure dynamische Tests

  • Prüft Konventionen, Standards, Design

  • Prüft nicht-funktionale Anforderungen (Service und Wartungsarbeit)

• Nachteile:

  • Nicht geeignet für Integrations-/Systemtests

  • Findet keine Laufzeitfehler

• Vorteile:

  • Die Software ist weniger fehleranfällig

  • Fehleranalyse ist einfacher

    • → Wenn ein Test fehlschlägt, weißt du sofort, wo das Problem liegt.

  • Redundanter oder toter Code wird vermieden

    • Du baust nichts, was keinen Test braucht → kein unnötiger Ballast

  
  

• Nachteile:

  • TDD betrachtet nur kleine Teile (Units)

    • Systemtests (z. B. wie alles zusammen funktioniert) fehlen oft

  • Es entstehen viele kleine Tests, die später nicht mehr sinnvoll sind

  • Man hat keinen Überblick über das große Ganze

    • Fokus liegt auf kleinen Funktionen, nicht auf Zusammenspiel und Architektur

    
    

  
  

  
  

  
  

• Methode vom Dynamischer Test

• Tester kennt den Quellcode

• Wird bei Unit- und Komponententest eingesetzt

• Inhalt

  • Tests gehen in den Code hinein

  • Kontrolliert z. B.:

    • Schleifen

    • Bedingungen (if, else)

    • Pfade im Code

  
  

• Wird in Systemtest und Abnahmetest / Validierungstest am häufigsten angewendet

• Ohne Codekenntnis

  • Test basiert auf dem Pflichtenheft

  • Getestet wird: Verhalten der Software

    
    

• Vorgehen:

  • Eingabe → Ausgabe prüfen

  • Erwartete Ergebnisse mit realen Ergebnissen vergleichen

• Aufwand:

  • Alle Testfälle abzudecken ist aufwendig

  • Daher: ähnliche Fälle zusammenfassen

  • Grenzen prüfen

    • wo am wahrscheinlichsten Fehler auftreten (z. B. maximale Auslastung, Sonderzeichen)

• Vorteile:

  • Laufzeitfehler werden gefunden

  • Zusammenspiel von Systemteilen kann getestet werden

  • Zeitverhalten ist testbar

  • Ressourcenverbrauch ist testbar

  • Auch nicht-funktionale Anforderungen können geprüft werden

• Nachteile:

  • Laufende Testumgebung muss vorhanden sein, oft aufwendig

  • Nur ausführbare Teile können getestet werden

  • Nur das Fehlverhalten wird sichtbar – nicht die Ursache

• Unit-/Modul-/Komponententest:

  • Einzelne Bausteine auf Funktion prüfen

  • Früh in der Entwicklung

    
    

• Integrationstest:

  • Zusammenspiel mehrerer unabhängige Systekomponenten testen

  • Fokus: Schnittstellen

  • Wenn mehrere Teile zusammen sind

• Systemtest :

  • Gestamsystem testen hinsichstlich Funktional + nicht-funktional Anforderungen

• Abnahmetest:

  • Kunde testet das System

  • Entscheidet über Annahme der Software

  • Ganz am Ende

• Funktionalität

• Zuverlässigkeit

• Benutzbarkeit

• Effizienz

• Änderbarkeit/ Wartbarkeit

• Übertragbarkeit

• Ziel: Testschritte und Ergebnisse müssen dokumentiert werden.

• Umfang: Hängt von Art und Größe des Projekts ab.

• Es gibt nicht immer alle 8 Dokumente – nur die passenden werden genutzt.

• Die Dokumente werden in 3 Kategorien eingeteilt.

• Testprotokoll gehört zur Testdokumentation

• Enthält Ergebnisse aller durchgeführten Testfälle

• Tester dokumentiert „OK“ oder „Fehler“

• Bei Fehlern: genaue Beschreibung des Fehlverhaltens