Qualitätsmanagement

Ursachen der Fehler:

• z.B. Kommunikationsprobleme
• Wichtig für Vermeidung zukünftiger Fehler

Phase der Fehlerentstehung:

• Meist Anforderungsanalyse und Entwurf
• Nicht immer eindeutig zuordenbar

Fehlerart:

• „Auslassung“ (omission)
• „(In)Korrektheit“ (comission)

Verteilung der Fehler auf einzelne Module (Pareto-Phänomen)

Fehler:

• Nichterfüllung einer festgelegten Forderung, insbes. eines Qualitäts- und Zuverlässigkeitsmerkmals (DIN EN ISO 8402)

Mangel:

• Nichterfüllung einer beabsichtigten Forderung oder einer angemessenen Erwartung DIN EN ISO 8402)
• Mit der angemessenen Erwartung gibt es beliebige Probleme
• Hier geht es oft um die nicht genau spezifizierte Benutzerfreundlichkeit

Unterscheidung wichtig für Auftragnehmer und Auftraggeber im Rahmen der Vertragsgestaltung

Aufgrund des Summationseffekts sind die Kosten umso höher ...

• je früher in der Entwicklungsphase der Fehler entsteht
• je später in der Entwicklungsphase der Fehler entdeckt wird

Testprozesse sind im Rahmen der Softwareentwicklung mit Aufwand und Kosten verbunden:

+ Testen senkt die Wartungskosten und

+ Gefahr von Folgekosten durch Fehler

+ Hohe Produktqualität

- Testen erhöht die Entwicklungskosten und verlängert die Projektdauer

- Entwicklungszeit vs. Fehlerhaftigkeit

Berechnung der Wirtschaftlichkeit durch Test-ROI:

• (Testnutzen – Testkosten) / Testkosten
• Je höher der ROI-Wert über 0, desto mehr lohnt sich Testen
• Werte kleiner gleich Null zeigen ungerechtfertigten Testaufwand
• Herausforderung: Ermittlung des Testnutzens und der Testkosten im Voraus
  • Ermittlung mit Hilfe von Durchschnittswerten (z.B. Fehler pro LOC)
  • Ermittlung mit Hilfe von speziellen Formeln

Qualität:

• „Qualität ist die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen“
• Qualität ist die Übereinstimmung mit den Kundenanforderungen, und zwar die mit den tatsächlichen Anforderungen der beteiligten Personen.
• Qualität entsteht während der Entwicklung und lässt sich nicht (oder nur sehr schwer) später einbauen.

Qualitätsmanagement (QM):

• Umfasst „alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen, sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen.“
• Qualitätsmanagement ist ein Teil des Gesamtmanagements und legt Kriterien und Maßnahmen zur Erreichung der Qualität fest

Qualitätssicherung (QS):

• Teil des Qualitätsmanagements, der darauf ausgerichtet ist, konkrete Qualitätsanforderungen zu erfüllen.
• Dokumente: QM-Handbuch, QM-Verfahrensanweisungen, Prüfanweisungen und Arbeitsanweisungen

• Das Qualitätsmanagement-System (QMS) sind die zur Verwirklichung des Qualitätsmanagements erforderliche Organisationsstruktur, Verfahren, Prozesse und Mittel.
• Angemessener Umfang zur Erreichung der gestellten Qualitätsziele
• Soll das QMS für vertragliche oder sonstige verpflichtenden Zwecke verwendet werden, ist es erforderlich, das QMS schriftlich festzulegen.

• Auch Modul-, Unit- oder Klassentest
• Systematischer Test von kleinsten Softwareeinheiten
• Durchführung in der Regel von Entwicklern
• Schon hier: Schwierigkeit des Vorhersagens korrekter Werte

Basis:

• Komponentenspezifische Anforderungen
• Softwaredesign (auch Quellcode)

Objekte:

• Isolierte Komponenten

Umgebung:

• Entwicklungsnah
• Einsatz von Testtreibern/Stubs

Ziele:

• Sicherstellung, dass Testobjekt die geforderte Funktionalität korrekt und vollständig realisiert
• Sicherstellung, dass Testobjekt robust reagiert
• Test auf Effizienz und Wartbarkeit

• Voraussetzung: Komponententest
• Test von Gruppen von Komponenten im Zusammenspiel
• Testobjekte werden komplizierter

Top-down:

• Start: Komponente, die weitere Komponenten aufruft, selbst aber nicht aufgerufen wird
• Einsatz von Stubs
• Komponenten niedrigerer Schichten werden sukzessive hinzu integriert

Bottom-up:

• Start: elementare Komponenten des Systems, die keine weiteren Komponenten aufrufen
• Einsatz von Testtreibern
• Komponenten höherer Schichten werden sukzessiv hinzu integriert

Basis:

• Software- und Systemdesign
• Systemarchitektur Workflows und Use Cases

Objekte:

• Zusammengesetzte Komponenten inkl. Fremdkomponenten

Umgebung:

• Wiederverwendung von Testtreibern/Stubs
• Monitore (Programme, die Datenbewegungen zwischen Komponenten mitlesen und protokollieren)

Ziele:

• Aufdeckung von Fehlerzuständen in Schnittstellen und im Zusammenspiel zwischen den integrierten Komponenten

• Voraussetzung: Integrationstests
• Überprüfung des integrierten Systems, ob die spezifizierten Anforderungen vom Produkt erfüllt werden

Leistungstest:

• Software-System wird an Grenzbereiche herangebracht (jedoch nicht darüber hinaus)
• Lasten müssen erzeugt werden und Zeiten und Auslastung gemessen werden
• Leistungstests werden mit geeigneter Werkzeugunterstützung durchgeführt

Stresstest:

• Überlastung des Software-Systems durch die Wegnahme von Ressourcen
• Ähnliche Werkzeugunterstützung wie bei Leistungstests
• Unterschied: Last über Grenzbereich hinaus (Überlastung)

Basis:

• Dokumente oder Informationen, die das Testobjekt auf Systemebene beschreiben (Anforderungsdokumente, Spezifikationen, Benutzerhandbücher, ...)

Objekte:

• Integriertes Gesamtsystem

Umgebung:

• Möglichst nah an der Produktivumgebung
• Vermeidung von Testtreibern und Stubs

Ziele:

• Validierung, ob und wie gut das fertige System die gestellten Anforderungen (funktionale und nicht-funktionale) erfüllt
• Identifikation von undokumentierten oder vergessenen Anforderungen

• Voraussetzung: Systemtest
• Beteiligung des Kunden, da Sicht und Urteil des Kunden bzw. Anwenders im Fokus
• Oft: von kommerziellen Interessen dominiert

Basis:

• Alle Dokumente oder Informationen, die das Testobjekt aus Anwendersicht beschreiben (UseCases, Prozessbeschreibungen, Gesetze, ...)

Objekte:

• Integriertes Gesamtsystem

Umgebung:

• In der Abnahmeumgebung des Kunden (möglichst nah an der Produktivumgebung)

Ziele:

• Test auf vertragliche Akzeptanz
• Test auf Benutzerakzeptanz
• Sicherstellung der Akzeptanz der Systembetreiber

Test auf Benutzerakzeptanz:

• Empfohlener Test, wenn Kunde und Anwender des Systems verschiedene Personengruppen sind
  • Sicherstellung, dass jede Anwendergruppe das System akzeptiert
  • Für jede Anwendergruppe spezifische Tests durchführen
• Tests werden (meist) vom Kunden selbst organisiert, der auch die Testfälle auswählt
• Wichtig: Für umfassende Änderungen auf Grund von gravierenden Akzeptanzproblemen oftmals zu spät
• Daher: Bereits frühzeitig auf Benutzerakzeptanz testen (z. B. mit Prototypen)

Produktorientiert:

• Software-Produkte und Zwischenergebnisse werden auf vorher festgelegte Qualitätsmerkmale überprüft
• Bei Anwendungs-Software gehören Gütebedingungen und Prüfbestimmungen dazu
• Diese können Gegenstand einer Zertifizierung sein, d.h. einer Bestätigung durch anerkannte (akkreditierte) Stellen, dass bestimmte Normen eingehalten wurden

Prozessorientiert:

• Bezieht sich auf den Erstellungsprozess der Software
• Dazu gehören Methoden, Werkzeuge, Richtlinien und Standards
• Alle Mitarbeiter müssen ein Qualitätsbewusstsein entwickeln, das den Produktionsprozess hin zu einer optimalen Qualität verändert

Konstruktiv:

• Methoden, Sprachen, Werkzeuge, Richtlinien, Standards und Checklisten, die dafür sorgen, dass das entstehende Produkt bzw. der Erstellungsprozess à priori bestimmte Eigenschaften besitzt
  • Dokumentenstandards für Anforderungsdokumentation
  • Entwurfsmuster für Softwarearchitektur
  • Projektmanagementwerkzeuge
  • Festlegung von Verantwortlichkeiten

Analytisch:

• Diagnostische Maßnahmen (ex post), d.h. sie bringen in das Produkt oder den Entwicklungsprozess keine Qualität ein, aber decken Fehler und Mängel auf
• Durch analytische Maßnahmen wird das existierende Qualitätsniveau gemessen
• Ausmaß und Ort der Defekte können identifiziert werden
• Das Ziel ist also die Prüfung und Bewertung der Prüfobjekte
• z.B. Reviews, Code-Inspektionen, Überprüfung schriftlicher Dokumente auf Vollständigkeit, Audits

• Testende Verfahren haben das Ziel, Fehler zu erkennen
• Getestet werden sämtliche Dokumente, die bei der Softwareentwicklung entstehen
• Prüflinge: Dokumente, die Testverfahren unterworfen werden
  • Dazu gehören die Produktdefinition, die Softwarespezifikation(en), der Quelltext, das ausführbare Programm und die Testdokumente selbst
• Testen ist eine Kontrollfunktion im Softwareentwicklungsprozess, sie umfasst nicht die Fehlerkorrektur
• Debuggen ist ein Prozess, bei dem die Ursache eines Fehlers lokalisiert, dessen Korrektur überlegt, die Folgen der Korrektur geprüft und die Korrektur durchgeführt wird -> anschließend: erneutes Testen („Retesting“)

Testfall:

• Testfälle umfassen Eingabewerte und die zu diesen Eingabewerten erwartete Ausgabewerte -> umfasst also eine Menge von Testdaten
• Testfälle decken sowohl erlaubte als auch unerlaubte Eingaben ab
• Protokollierung eines Testfalls (Ergebnis, Plattform, Tester, Version, Datum)
• Rückbezug von Testfällen zu Anforderungen (welche Anforderungen werden durch Tests überprüft, welche werden erfüllt)

Testdatum:

• Besteht aus einem Eingabe- und einem Soll-Datum

Eingabedatum:

• Ist ein Tupel von Werten für alle Eingabevariablen eines Programms
• Komponenten des Eingabedatums heißen Testwerte

Ist-Datum:

• Ist das Ergebnis, das erzeugt wird, wenn das Programm mit einem Eingabedatum ausgeführt wird

Soll-Datum:

• Ist ein gemäß Spezifikation gewünschtes Ergebnis, das erzeugt werden sollte, wenn das Programm mit einem Eingabedatum ausgeführt wird
• Frage: Woher kommt dieser Wert? -> Testorakel

• Idealerweise sollten Test Orakel generiert werden
• Typischerweise sind Test Orakel jedoch Menschen (verwenden z.B. die Anforderungsspezifikation)

Probleme:

• Auch die Sollvorgaben können fehlerhaft sein
• In der Praxis werden neue Softwaresysteme oft gegen alte getestet. Bei konsequenter Handhabung werden Fehler in den Altsystemen in den neuen nachgebaut! Einem sinnvollen Testorakel kommt deshalb besondere Bedeutung zu.

Defekt:

• Bei einem Defekt weicht ein Merkmal der Beobachtungseinheit von seiner Spezifikation ab
• Defekte können, müssen aber nicht die Funktionstüchtigkeit des Prüflings beeinträchtigen
• (z.B. fehlerhaft realisierte operative Anforderungen, aber auch mangelhafte Lesbarkeit, Verletzung von Dokumentationsrichtlinien)

Fehler:

• Ein Fehler ist das Abweichen eines berechneten, beobachteten und gemessenen Wertes oder eines Zustandes der Betrachtungseinheit von dem entsprechenden spezifizierten oder theoretisch richtigen Wert bzw. Zustand (z.B. die Ausgabe eines falschen Funktionswertes)
• Ein Fehler ist immer auch ein Defekt

Ausfall:

• Die Betrachtungseinheit ist nicht mehr in der Lage, die geforderte Funktion auszuführen (z.B. Programmabsturz, Deadlock-Zustand)
• Es liegt eine grobe Verletzung der Zuverlässigkeit vor

• Für einen Tester stellt sich beim Testen die Frage, wann er den Prüfling ausreichend getestet hat, d.h. wann kann er mit dem Testen aufhören.
• Der Überdeckungsgrad ist ein Maß für den Grad der Vollständigkeit eines Tests bezogen auf ein bestimmtes Testverfahren.

• Unter einem Regressionstest versteht man die Wiederholung von Testfällen
• Hat man einen Prüfling z.B. mit 50 Testfällen getestet und möchte später Änderungen am Prüfling vornehmen, wäre es sehr zeitaufwendig, alle 50 Testfälle erneut einzugeben
• Ein Testwerkzeug sollte daher einen (teil-)automatisierten Regressionstest ermöglichen.
• Das Testwerkzeug speichert alle durchgeführten Tests und erlaubt die automatische Wiederholung aller bereits durchgeführten Tests nach Änderungen des Prüflings, verbunden mit einem Soll/Ist-Ergebnisvergleich.

White-Box (auch struktureller oder implementationsorientierter Testansatz genannt):

• Testfälle und Testdaten werden durch strukturelle Analyse des Programms erzeugt
• Kontroll- und Datenfluss ist in der Regel Informationsbasis
• Auf diese Flüsse beziehen sich Überdeckungskriterien, die eine relevante Teilmenge aller möglichen Programmpfade definieren
• Eine hinreichende Testdatenmenge ist dann eine Menge von Eingabedaten, die alle über das Überdeckungskriterium bestimmten Programmpfade ausführen

Black-Box (auch funktionaler Testansatz genannt):

• Testfälle und Testdaten werden durch Analyse der Spezifikation erzeugt ohne Berücksichtigung der internen Struktur des Programms
• Güte der erstellten Testdaten ist abhängig von der semantischen Aussagekraft der Spezifikation und von Verfahren zur Auswahl der Testdaten

White-Box:

+ Automatische Tests möglich, da Programm als Testbasis mit wohldefinierter Syntax und Semantik

+ Programme können ohne Spezifikation getestet werden

+ Implementierte, aber nicht spezifizierte Programmteile werden getestet

- Spezifizierte, aber nicht implementierte Programmteile werden nicht entdeckt

Black-Box:

+ Spezifizierte, aber nicht implementierte Programmteile werden entdeckt

+ Aussagekräftige Spezifikation erlaubt systematisches Erstellen von Testdaten (z.B. zum Testen von formal definierten Integritätsbedingungen)

+ Wiederverwendung von Testdaten für verschiedene Plattformen

- Implementierte, aber nicht spezifizierte Programmteile werden nicht entdeckt und nicht getestet

- Wenig aussagekräftige Spezifikation führen zu unrepräsentativen Testdaten

• sind white-box-Verfahren, denn sie nutzen die Kenntnis der Programmstruktur aus.
• Sie sind dynamische Verfahren, denn sie basieren auf der Ausführung des Programms mit verschiedenen Testdaten

Ziel:

• Testdaten so wählen, dass möglichst viele Durchläufe durch den Kontrollfluss des Programms getestet werden und dass dafür möglichst wenig Testfälle gebraucht werden
• Die Varianten der kontrollflussbezogenen Verfahren differenzieren nach angestrebtem Überdeckungsgrad und nach Art und Weise, in der der Begriff der Überdeckung verstanden wird

Analysemittel:

• Kontrollflussgraph: Verdeutlicht den Kontrollfluss in einem Programm

Berechnungsfehler:

• richtiger Kontrollflussweg wird ausgeführt, aber mindestens ein berechneter Variablenwert ist falsch

Bereichsfehler:

• falscher Kontrollflussweg wird ausgeführt, weil der Eingabebereich nicht korrekt ist

Unterbereichsfehler:

• ein Kontrollfluss zu wenig oder zu viel im Programm, d.h. es fehlt eine Abfrage oder es gibt eine zusätzliche, falsche Abfrage

Der Kontrollflussgraph eines Programms P ist ein gerichteter Graph G = (N,E) mit 2 ausgezeichneten Knoten nstart ,nfinal (Anfangs- und Endanweisung).

Bestandteile:

• Knoten
• Kante
• Block
• Pfad/vollständiger Weg
• Wege (T,P)
• Zyklus
• Entscheidungs-Entscheidungsweg
  • beginnt bei einem Entscheidungsknoten oder dem Anfangsknoten
  • enthält alle folgenden Knoten und Kanten bis
  • zum nächsten Entscheidungsknoten bzw. bis zum Endknoten (einschließlich)
• Segment
  • beginnt mit dem Anfangsknoten, einem Entscheidungsknoten oder einem Vereinigungsknoten (mehrere Inputs).
  • letzter Knoten ist der Endknoten, ein Entscheidungsknoten oder ein Vereinigungsknoten
  • Alle andere Knoten haben nur eine Eingangs- und eine Ausgangskante

• Anweisungsüberdeckung (jede Anweisung ausgeführt?)
• Zweigüberdeckung (jeder Zweig ausgeführt?)
• Bedingungsüberdeckung (jede Bedingung ausgeführt?)
  • einfach/atomar (jede Entscheidung einmal true, einmal false)
  • mehrfach (alle Kombinationen der Bedingungen)
  • minimal mehrfach (jede Bedingung einmal true, einmal false)

Unsystematische Black-Box-Verfahren:

• Zufälliges Testen (Random Test)
  • Testfälle werden auf Basis einer wahllos gebildeten Untermenge aller möglichen Eingabedaten des spezifizierten Eingabebereichs gebildet
• Fehlererwartungsmethode (Test spezieller Werte)
  • Erfahrene Tester kennen typische Fehler und bilden Testfälle auf Basis von Fehlerlisten

Systematische Black-Box-Verfahren (Auswahl):

• Äquivalenzklassenbildung / Äquivalenzklassentest
  • Um eine repräsentative Menge von Eingabedaten zu testen, werden die möglichen Eingaben in Äquivalenzklassen eingeteilt. Danach wird aus jeder Klasse jeweils ein Repräsentant gewählt
• Grenzwertanalyse
  • An den Grenzen zulässiger Datenbereiche treten häufig Fehler auf
  • Es werden Testfälle für solche Grenzfälle definiert

• In der Regel ist es unmöglich das Prüfobjekt mit sämtlichen Kombinationen der Eingabewerte zu testen
• Lösung: Unterteilung der Eingaben in „Gruppen ähnlicher Werte“ (Äquivalenzklassen)
• Ausgangspunkt: Spezifikation des „Testobjekts“ als Funktion

Vorgehen:

• Aufstellung von Eingabebedingungen (z.B. Satz oder Abschnitt aus Spezifikation)
• Bildung von Äquivalenzklassen
• Definition von Eingabedaten mit Hilfe der Äquivalenzklassen
• Idealerweise gilt: Test 1 mit Wert x aus Äquivalenzklasse K ist zu Test 2 mit Wert y aus Äquivalenzklasse K äquivalent
• Knackpunkt des Verfahrens: Sind immer alle Werte einer Äquivalenzklasse äquivalent?

• Ansatz der Programmentwicklung, bei dem Testen und Codeentwicklung ineinandergreifen
• Test-Driven Development ist eine Technik der agilen Softwareentwicklung
• Schnelles Testen, auch um Anwender früh einzubeziehen und um Texterstellung durch Code-Erstellung zu ersetzen
• Grundgedanke: Software-Tests erstellen, bevor die dazugehörigen Funktionalitäten implementiert werden
• Test dient als Spezifikation der Annahmebedingungen. Soll heißen: bestandener Test bedeutet Akzeptanz durch Anwender

Prinzip/Mantra:

• Neuer Code wird erst dann hinzugefügt, wenn ein automatisierter Test fehlschlägt
• Soll heißen: Am Anfang steht der Testfall, der mangels Code fehlschlägt
• Code hinzufügen damit der Test bestanden wird
• Durch Refactoring zu einem sauberen Code ohne Duplikationen gelangen
• Tradeoff im Refactoring: funktionaler Fortschritt versus sauberer Code

• Reduzierung von Fehlern im Code
• Klare Vorstellung, wie das Ergebnis für eine individuelle Komponente aussehen soll
• Qualitätssicherung kann von reaktiver Arbeitsweise auf eine proaktive wechseln
• Zusätzliche Debugging-Sessions zur Fehlersuche können vermieden werden
• Durch eine geringere Zahl an unvorhersehbaren Fehlern können Aufwände exakter abgeschätzt und dem Kunden kommuniziert werden
• Eine geringere Fehlerzahl führt zu kürzeren Release-Zeiten
• Durch das Erstellen von kleinen Tests, welche nach und nach erfüllt werden, wird ein Überblick geschaffen, so dass es möglich wird, zu sehen, wie weit man im Projekt fortgeschritten ist
• Fehlerwellen fallen flacher aus, es herrscht ein ausgeprägtes Gefühl „alles unter Kontrolle zu haben“

• Risiko ähnlich wie bei der Einführung anderer agiler Techniken
• Generell minimieren agile Methoden nicht die Lebenszykluskosten, sondern maximieren Business Value durch das Ausliefern funktionierender Software
• Ob TDD und agiles Vorgehen sinnvoll ist, hängt von den Prioritäten ab: Qualität, Kosten, Produktivität, Geschwindigkeit, Projekterfolg, ...
• TDD kann das Risiko senken: Frühes Identifizieren von Fehlern verringert die Änderungskosten im Laufe des Projektes

• Beim Test-Driven Development werden hauptsächlich Unit Tests verwendet
• Ein Modul (Unit) ist in der Regel eine individuelle Klasse
• Mock-Objekte werden dabei verwendet, um die Interface-Anforderungen der Module zu simulieren und sind dabei weniger komplex als die richtigen Module
• Dabei helfen Mock-Objekte, die Tests auf das Verhalten des Systems zu fokussieren, ohne dass auf Abhängigkeiten geachtet werden muss
• So können beispielsweise verschiedene Objekte in einem bestimmten Zustand simuliert werden, auf die der zu testende Algorithmus angewiesen ist
• Wenn später die Mock-Objekte durch reale, komplexere, Module ersetzt werden, wird zum Integrationstest übergegangen

• Erweiterung des TDD: Domänenexperten sollten Tests definieren können
• Technische Umsetzung sollte keine Rolle spielen
• Domain Specific Language
  • Dokumentation des Domänenwissens
  • Zusammenarbeit Qualitätsmanagement und Business-Analyse stärken
• Beispiel Gherkin:
  • Feature
  • Scenario
  • Given, When, Then, And
  • Background
  • Examples
• Testing-Framwork (z.B. Cucumber)
  • Ausführung der Tests
  • Erzeugung von Runner für Unit testing Framework (JUnit)
  • Annotationen für Java
• Before und After erlauben Aufbauen einer Testumgebung und Aufräumarbeiten
• Given erlaubt Parameter-Aufnahme aus Examples
• When bezeichnet Aktionen
• Then erlaubt Tests auf entsprechende Reaktion