Was bedeudet Software testen und dokumentieren?
Warum ist es wichtig früh zu testen und was passiert bei späten Fehlern?
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.
Früh testen & dokumentieren spart Kosten.
Fehler früh entdecken = billiger zu beheben.
In der Entwicklungsphase sind Fehler leicht zu korrigieren.
Im Live-Betrieb ist die Korrektur aufwendig und teuer.
Warum werden Fehler nicht in der Enwicklungsphase endeckt
mangelhafter nicht vorhandener Testprozess
Gleiche gilt für Dokumentation
Je früher man anfängt desto präziser fällt diese aus
Warum sind Test keine Garantie für Fehlerfreiheit?
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
Was ist der Unterschied zwischen einem Lastenheft und einem Pflichtenheft?
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“
Welche Erhebungstechniken gibt es in der Softwareentwicklung und wann werden sie eingesetzt?
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
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
„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?“)
Viele Ideen für Lösungen oder Probleme finden
Welche Phasen umfasst ein Projekt im Projektmanagement und was ist jeweils das Ergebnis?
Vorbereitungsphase
Ergebnis: Projektskizze, Team, Projektrahmen, Informationswege
Definitionsphase
Ergebnis: Lösungskonzept, Projektziele, Projektvertrag
Planungsphase
Ergebnis: Projektplan
Realisierungsphase
Ergebnis: Projektergebnis (Umsetzung)
Abschlussphase
Ergebnis: Abnahmen, Dokumentation, Abschlussunterlagen
Wie funktioniert das vorgehensmodell extreme programming und worauf liegt der schwerpunkt?
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
Wie ist das V-Modell aufgebaut und wann wird es in der Softwareentwicklung eingesetzt?
Phasen:
Systemanforderungen <- Abnahmetest/Valedirungstest
Systementwurf <- Systemtest
Systemarchitektur <- intigrationstest
Komponentendesign <- Komponententest
Implementierung / Codierung <- Unitest
Typische Tests:
Stresstest, Langzeittest
Eingabevalidierung
Beta-Version
Wie läuft testgetriebene Entwicklung (TDD) ab und was ist das Grundprinzip dahinter?
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
Was ist das Ziel des Testprozess
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
Was sind entscheidene Punkte der Testplanug
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)
Was ist das Ergebnis der Testplanung und Testentwurf?
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
Was passiert bei der Testvorbereitung und Testdurchführung?
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
Was ist das Ergbnis von Testauswertung und Testabschluss?
Testauswertung:
Auswertung der Testergebnisse und vergleich mit den erwarteten Testergebnisse
Entscheidungüber bestanden oder nicht bestanden
Testabschluss:
Abschluss der Dokumentation der Testergebnisse
Was sind statische und dynamische Testverfahren
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
Whitbox-Test
Du testest das Programm, und du kennst den Quellcode
Blackbox-Test
Du testest das Programm ohne den Quellcode zu kennen
Was wird in statische Testverfahren getestet
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
Was sind Vor- und Nachteile der stastische Testverfahren
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
Was sind die Vor und Nachteile von Testgetriebene Entwicklung (TDD)?
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
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
Was ist Whitebox-Test?
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
Was ist Blackbox-Test?
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)
Was sind die Vor- und Nachteile von dynamische Testverfahren?
Laufzeitfehler werden gefunden
Zusammenspiel von Systemteilen kann getestet werden
Zeitverhalten ist testbar
Ressourcenverbrauch ist testbar
Auch nicht-funktionale Anforderungen können geprüft werden
Laufende Testumgebung muss vorhanden sein, oft aufwendig
Nur ausführbare Teile können getestet werden
Nur das Fehlverhalten wird sichtbar – nicht die Ursache
Wie verlaufen dynamische Testverfahren im Softwareentwicklungsprozess?
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
Was muss man bei der ISO/IEC 9126 dynamischer Testverfahren
Funktionalität
Zuverlässigkeit
Benutzbarkeit
Effizienz
Änderbarkeit/ Wartbarkeit
Übertragbarkeit
Was ist das Ziel der Testdokumentation und wovon hängt ihr Umfang ab?
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.
Was ist Testprotokoll?
Testprotokoll gehört zur Testdokumentation
Enthält Ergebnisse aller durchgeführten Testfälle
Tester dokumentiert „OK“ oder „Fehler“
Bei Fehlern: genaue Beschreibung des Fehlverhaltens
Zuletzt geändertvor 2 Tagen