IUBH Qualitätssicherung im Softwareprozess IQSS

• Professionelle und gute Zusammenarbeit der am Prozess beteiligten Personen
• Maßnahmen sind Qualifizierungen, gemeinsame Aktivitäten und die Gestaltung des Arbeitsumfelds.
• Qualifizierungen
  • Entwicklung persönlicher und fachlicher Kompetenzen durch Trainings oder Coachings.
• Gemeinsame Aktivitäten
• Arbeitsumfeld
  • Schaffung von ausgewiesenen Ruhezonen
  • Zusammensetzen von Teammitgliedern in Projektbüros 
  • Einsatz von Kanban-Boards

• Eigentliche Fehlerursache von Fehlersymptomen zu identifizieren.
• „Ask ‘why’ five times about every matter“.
• So kann in diesem Fall die ursprüngliche Ursache für den Fehler lokalisiert werden.
• Zur nachhaltigen Behebung des Fehlers können gezielte Schulungsmaßnahmen durchgeführt werden

Beispiel:

Komponente Warenkorb werden überdurchschnittlich viele Fehler gemeldet.“

1. Warum-Frage: Warum werden Fehler gemeldet? Antwort: Weil die Berechnung Gesamtsumme häufig etwas von der Summe der Einzelpositionen abweicht.

2. Warum-Frage: Warum weicht die Gesamtsumme ab? Antwort: Weil bei der Berechnung von Rabatten für Premiumkunden Rundungsfehler auftreten.

3. Warum-Frage: Warum treten Rundungsfehler auf? Antwort: Weil bei der internen Berechnung von Zwischenergebnissen diese nicht in der erforderlichen Genauigkeit gespeichert werden.

4. Warum-Frage: Warum kann die Genauigkeit nicht erreicht werden? Antwort: Weil ein Datentyp zur Speicherung gewählt wurde, der alle Nachkommastellen ab der 3. Stelle nicht speichert.

5. Warum-Frage: Warum wurde dieser Datentyp ausgewählt? Antwort: Weil der Entwickler immer davon ausgegangen ist, dass zu Beträgen niemals mehr als 2 Nachkommastellen gespeichert werden müssen.

Schritt 1: Sammlung aller verfügbaren Informationen zum Fehler und dem durch den Fehler ausgelösten fehlerhaften Verhalten.

Schritt 2: Anwenden der 5-Why-Methode.

Schritt 3: Identifikation der Stellen im Programmcode, die verändert werden müssen, um den Fehler zu beseitigen.

Schritt 4: Identifikation möglicher (konstruktiver und analytischer) QS-Maßnahmen, um den Fehler zukünftig zu vermeiden.

Schritt 5: Einführung der QS-Maßnahmen.

Schritt 6: Evaluation der QS-Maßnahmen, ob durch sie die Fehler zuverlässig verhindert wurden.

• Technik der Projektplanung, die für Aktivitäten einen festen und unveränderlichen Zeitrahmen vorsieht.
• In der agilen Softwareentwicklung weit verbreitet (Durchführung von Meetings).
• Durch Vorgabe eines strengen Rahmens zu hoher Besprechungsqualität zu kommen.
• Häufig wird für Besprechungen ein fester Zeitrahmen gesetzt, der allen Teilnehmern bekannt gemacht wird.
• Wird das Timeboxing neu eingeführt, muss ein Moderator bestimmt werden, der die Einhaltung überwacht.

• Sie dienen dabei zur Sicherstellung, dass im Rahmen einer Aufgabe keine erforderliche Aktivität vergessen wird
• Kontrolliert ob alle benötigten Ergebnis- oder Managementartefakte am Ende der Aufgabe vorliegen.
• Checklisten werden in der Regel zu sich wiederholenden Standardaufgaben erstellt
• Ein Punkt auf der Checkliste entspricht genau einem Ziel, zusammengesetzte Ziele sollten vermieden werden
• Eine Checkliste sollte nicht größer als ein DIN A4-Blatt sein,

Verfahren:

• Reviews
• statische Codeanalyse

Prüfen:

• Prüfen der fachlichen Anforderungen
• Quality Gates
• Prüfen der technischen Spezifikation
• Bewertung der geplanten Architektur
• Testfallerstellung
• Komponententests

• Eine Review-Technik ist ein statisches manuelles Prüfverfahren zur Analyse eines Prüflings
• Techniken, die sich hinsichtlich des Aufwandes und Grades der Strukturierung unterscheiden.
• So ist eine Stellungnahme eine sehr einfache und wenig aufwendige, eine Inspektion hingegen eine sehr stark strukturierte und aufwendige Begutachtungstechnik.
• Je nach Art, Ziel und Organisation des Reviews, werden einzelne Phasen weniger intensiv oder gar nicht durchgeführt.

• Stellungnahme
• Walkthrough
• Inspektion

Inspektion

• Moderator
• Gutachter
• Autor
• Protokollführer

Walkthrough

• Moderator (bei Bedarf)
• Gutachter
• Autor

Stellungname

• Gutachter
• Autor

• Planung
• Vorbesprechung (bei Bedarf)
• Vorbeeitung der Gutachter
• Review
• Nachbearbeitung
• Bewertung

• Die einfachste und schnellste Technik des Reviews ist eine informelle Stellungnahme.
• Dabei wird der Prüfling durch eine an der Erstellung unbeteiligten und unabhängigen Person gelesen und hinsichtlich der relevanten Prüfkriterien bewertet.
• Mängel werden markiert und kurz begründet.
• Der Ablauf folgt dabei keinem bestimmten Schema oder Vorgaben.

• Unterschied zur Stellungnahme das Dokument bei einem Walkthrough von mehreren Personen gelesen und die identifizierten Mängel werden in der Gruppe diskutiert und bewertet.
• Ein Walkthrough muss keinen formalen Kriterien entsprechen, der Aufwand für die Organisation und Koordination ist jedoch größer.
• Je nach Bedarf und Projektsituation kann die Rolle des Moderators durch den Autor oder durch eine neutrale Person ausgeführt werden.
• Durch den Einsatz mehrerer Gutachter kann eine detailliertere Prüfung erfolgen

• Formles Review mit in der Regel mehreren Gutachtern,
• Festgelegter Ablauf, Durchführung und Ergebnisse werden ausführlich dokumentiert.
• Die Organisations- und Durchführungskomplexität ist im Vergleich größer,
• Rollen eines Moderators und Protokollanten explizit gefordert.
• Wird bei wichtigen Prüflingen durchgeführt, in denen nicht identifizierte Mängel ein hohes Schadenspotenzial haben. 

• Eine Technik zur Kommunikation von Feedback zu Arbeitsergebnissen und dient der Aufrechterhaltung der Kooperationsbereitschaft der beteiligten Stakeholder.
• Lob -> Kritik -> Lob

• unvoreingenommen Lesen

• Feedback vorbereiten

• Feedback geben

• Zur Bestimmung der Qualität von Produkten und Prozessen 
• Funktion, die aus den Ergebnissen der Vermessung eines Prüflings einen Zahlenwert ermittelt, wird Metrik genannt.
• Qualitätskontrolle/Verbesserung von Ergebnissen/Prozessen. 
• Auf Grundlage der Werte werden Aussagen über den Zustand des Produktes oder des Prozesses abgeleitet.
• Es gibt Metriken zur Bewertung von Prozessen und  zur Bewertung von Artefakten.
• Softwareprozess
  • Verbrauchte Ressourcen (Zeit, Geld, Personal),
  • Anzahl der identifizierten Fehler im Projekt,
  • Dauer einzelner Aktivitäten,
  • Mittlere Behebungszeit von identifizierten Fehlern
  • Anzahl von Änderungen an einer Systemkomponente.
• Artefakte
  • Umfang (Anzahl Seiten, LOC, Anzahl Modellelemente), 
  • Komplexität,
  • Qualität (Anzahl identifizierter fachlicher Fehler, Anzahl identifizierter formaler Fehler),
  • Stabilität (Grad der Änderungen in einem bestimmten Zeitraum) 
  • Stil (Einhaltung von Konventionen, Lesbarkeit, Redundanzfreiheit).

• Zur Bestimmung der Komplexität von Softwarekomponenten 
• Dabei werden zunächst konkrete Basiswerte im Programmcode gemessen, aus denen dann anschließend verschiedene Metriken berechnet werden.

• Fan-in: Metrik zu einer Komponente, welche die Anzahl der Funktionen außerhalb einer Komponente bestimmt, die die Funktionen der betrachteten Komponente aufrufen
•  
• Fan-out: Metrik zu einer Komponente, welche die Anzahl der Funktionen zurückgibt, die von der betrachteten Komponente auf andere Komponenten aufgerufen werden.

• Grad von Vererbungsbäumen
• Tiefe einer Klasse
• Anzahl der direkten Unterklassen einer Klasse (NOC);
• Kopplung zwischen Objekten (CBO): Anzahl der Klassen, die Methoden der gemessenen Klasse benutzen.
  • Je höher die Kopplung zwischen Objekten ausgeprägt ist, umso aufwendiger wird es, die Klassen zu testen oder wiederzuverwenden;
• Response for a class (RFC): Anzahl aller möglichen ausführbaren Methoden einer Klasse, dazu zählen sowohl die Methoden, die in der Klasse implementiert werden, als auch die Methoden, welche (durch Kopplung) in anderen Klassen aufgerufen werden können

Vorteile

• Softwaremetriken sind relativ einfach zu ermitteln.
• Es Plugins, mit denen die Werte per Knopfdruck ermittelt und angezeigt werden können.
• Die meisten Metriken unabhängig von der konkreten Programmiersprache
• Softwaremetriken sind ein einfaches Mittel um vielfältige Eigenschaften von Ergebnisartefakten zu ermitteln.

Nachteile

• Aussagen über die tatsächliche Konsequenz bestimmter Eigenschaften insbesondere mit Softwaremetriken oft nicht möglich.
• Es lassen sich auf Basis von Softwarevermessungen in der Regel keine gesicherten tatsächlichen Konsequenzen ableiten.
• Sagt noch nichts darüber aus, ob das System die Anforderungen des Kunden erfüllt.
• Gefahr, dass die Erfüllung der Metrik stärker in den Vordergrund rückt als die Erfüllung von fachlichen Anforderungen.
• Daher eignen sich Metriken nur sehr bedingt, um aus ihnen konkrete Aussagen über die Qualität von Systemen oder Prozessen abzuleiten.

• Qualitative Bewertung von Programmcode.
• Im Unterschied zu Metriken werden bei der statischen Codeanalyse keine Eigenschaften des Programmcodes gemessen, sondern der Code wird inhaltlich analysiert und ausgewertet.
• Automatische Stilüberprüfung und die Analyse nach typischen Fehlermustern.
• Es gibt Werkzeugen für die statische Codeanalyse(Entwicklungsumgebungen /automatischen Build-Prozess )

• Automatische Stilanalyse mit Checkstyle

• Quelltextanalyse mit PMD

• Bytecode-Analyse mit FindBugs

• Zählen zu den analytischen QS-Maßnahmen.
• Sie werden auch testende Verfahren, Softwaretests oder auch nur Test genannt.
• Diagnostische Maßnahmen zur Prüfung und Bewertung der Qualität von Softwareartefakten nach deren Erstellung.

• Komponententest
• Integrationstest
• Systemtest
• Abnahmetest

Dient als Handlungsanweisung zur Durchführung von Softwaretests und besteht mindestens aus :

• Vorbedingungen, die vor dem Prüfschritt sichergestellt werden müssen
• Testdaten /Testaktionen, die während des Prüfschrittes eingegeben bzw. durchgeführt werden;
• Nachbedingungen, deren Erfüllung nach dem Prüfschritt geprüft wird;
• Beschreibende Daten zum Testfall(Name, ID, Komponente, Funktion/ Eigenschaft, Anwendungsfall, Autor)

• Prüfung aller in der Spezifikation geforderten Funktionen und Eigenschaften zu einem System/Systemkomponente.
• Über die innere Struktur des Prüflings liegen keine Informationen vor, d
• Der Tester interpretiert die Spezifikation, erstellt er anhand Interpretation die Testfälle und führt diese aus.
• Anschließend beurteilt der Tester die Testergebnisse anhand seiner Interpretation der Spezifikation.
• Sehr anwendernah und werden in der Regel bei Integrations-, System-und Abnahmetests eingesetzt.

• Werden mit Kenntnis des Programmcodes erstellt,
• Ziel ist eine möglichst große Abdeckung der im Programmcode implementierten Anweisungen/ Kontrollstrukturen
• Nachdem Programmcodes implementiert ist, wird die tatsächlich erzeugte Struktur des Codes analysiert. Auf dieser Basis werden dann Testfälle formuliert, nach der Ausführung werden die Ergebnisse ausgewertet und bei Bedarf der Programmcode angepasst, bevor erneut getestet wird.
• Auch Entwicklertests genannt.

• Ziel der QS-Maßnahmen ist eine kostenoptimale Qualitätssicherung.
• Bei der Durchführung von müssen sich Tester auf eine gezielte Auswahl von Testfällen und Testdaten beschränken.
• Ein Maß für die Vollständigkeit von Testfällen ist die sogenannte Testabdeckung.
• Je nach der eingesetzten Methode kann anhand der Testfallerstellung bestimmt werden, wie „vollständig“ die Menge der formulierten Testfälle das System prüft.

• Das Testen von Informationssystemen immer ein Stichprobenverfahren.
• Die Korrektheit von Systemen kann mit Tests nicht nachgewiesen werden.
• Eine der wesentlichen Herausforderungen beim Testen ist somit die Auswahl geeigneter Testfälle und Testdaten

• AnwendungsfallbasierteTestfallerstellung
• Äquivalenzklassenbildung
• Grenzwertanalyse
• ZustandsbasierteTestfallerstellung
• Erstellung von Zufallstestdaten
• Ursache Wirkungs Analyse
• Anweisungsüberdeckung
• Zweigüberdeckung
• Bedingungsüberdeckung
• Pfadtest
• Entscheidungstabelle
• Exploratives Testen

• Testfälle werden aus den fachlichen Anwendungsfällen(Use Cases) abgeleitet.
• Es sollte mindestens zu jedem Anwendungsfall ein Testfall erstellt werden.
• Häufig umfassen Use Cases mehrere komplexe fachliche Abläufe, In diesem Fall können durch Analyse des Aktivitätsdiagramms verschiedene Testfälle für den Use Case abgeleitet werden.
• Wenn keine UML-Diagramme erstellt wurden, muss der beschreibende Text zu dem Use Case analysiert werden.

• Wertbeitrag: Wie hoch ist der Beitrag dieser Funktion zur Wertschöpfungskette?
• Nutzungshäufigkeit: Wie viele Nutzer greifen wie häufig auf die Funktion zu?
• Schadenspotential: Welcher Schaden kann durch nicht identifizierte Fehler in der Funktion entstehen?
• Typische Fehler: Welche Funktionen bergen häufig Fehler in der Umsetzung? Wo sind die typischen Schwachstellen bei vergleichbaren Alt- oder Konkurrenzsystemen?
• Geforderte Testabdeckung: Welcher Grad der Testabdeckung ist für die fachliche Ebene tatsächlich gefordert?

Kriterien für die geforderte Testabdeckung:

• Anweisungsüberdeckung: Jede Funktion wird mindestens 1 x aufgerufen.
• Zweigüberdeckung: Jeder Kontrollflusspfeil wird mindestens 1 x durchlaufen.
• Bedingungsüberdeckung: Jede Bedingung wird mindestens 1 x zu WAHR und 1 x zu FALSCH ausgewertet.
• Pfadtest: Jeder mögliche Pfad durch den Use Case wird vollständig („am Stück“) durchlaufen,dabei werden mögliche Schleifen berücksichtigt.

• Technik zur Auswahl konkreter Testdaten bei der Testfallerstellung auf der Ebene von Funktionen.
• Alle möglichen Eingabewerte, die zu einer Funktion gemacht werden können, in Äquivalenzklassen einteilen.
• Alle Eingabewerte, die in ein fachlich identisches Systemverhalten resultieren, werden zusammengefasst
• Bei der Durchführung der Tests müssen dann nur jeweils ein beliebig ausgewählter Vertreter aus jeder Äquivalenzklasse getestet werden
• Anzahl der benötigten Testdaten pro Testfall sehr deutlich rduziert.
• Einsatz: GUI-Tests /Tests von technischen Schnittstellen

• Gültige B1: alle Zahlen zwischen 7 und 20: {x|7 <= x <= 20 und x ist ganze Zahl}
• Ungültige B2: alle Zahlen kleiner als 7: {x|x < 7}
• Ungültige B3: alle Zahlen größer als 20: {x|20 < x}

1. Äquivalenzklassen für jeden Eingabeparameter der Funktion bzw. jedes GUI-Element der Dialogmaske bestimmen und eindeutig kennzeichnen. Das Ergebnis von Schritt 1 kann bei Bedarf aus Gründen der Übersichtlichkeit in einer Tabelle dokumentiert werden.

2. Testfälle erstellen, mit denen alle gültigen Äquivalenzklassen abgedeckt werden. Die Anzahl der erforderlichen Testfälle ist dabei so gering wie möglich zu halten. Daher sollte die Kombination der Testdaten so gewählt werden, dass in möglichst wenig Testfällen möglichst viele Äquivalenzklassen getestet werden. Grundsätzlich sollte jede Äquivalenzklasse nur einmal getestet werden, denn eine Wiederholung von Tests mit den gleichen Daten bringt keinen zusätzlichen Erkenntnisgewinn.

3. Testfälle erstellen, mit denen alle ungültigen Äquivalenzklassen abgedeckt werden. Im Unterschied zu den Testfällen für gültige Äquivalenzklassen werden bei den Testfällen für ungültige Äquivalenzklassen pro Testfall nur eine ungültige Äquivalenzklasse getestet. Alle anderen Testdaten werden aus gültigen Äquivalenzklassen genommen. So kann im Fall eines fehlgeschlagenen Tests die betreffende ungültige Äquivalenzklasse einfacher identifiziert werden. Würden mehrere ungültige Äquivalenzklassen in einem Testfall getestet, kann im Fall eines Fehlschlags des Tests nicht sicher gesagt werden, welche der ungültigen Äquivalenzklassen die Ursache dafür ist.

4. Erstellung von konkreten Eingabedaten auf Basis der ausgewählten Äquivalenzklassen für jeden Testfall. Zum Testen der Beispielfunktion wurden insgesamt neun Testfälle identifiziert.

Vorteile

• Einfache Technik zur Ermittlung von Testdaten und Testfällen.
• Kann für jede technische /fachliche Funktion eingesetzt werden, die Eingabedaten erwartet.
• Auf Basis der tabellarischen Darstellung ist sowohl eine einfache Erstellung der Testfälle als auch eine intuitive Dokumentation möglich.

Nachteile

• Fachliche Abhängigkeiten zwischen einzelnen Äquivalenzklassen werden dabei jedoch nicht mit berücksichtigt, jede Äquivalenzklasse ist grundsätzlich unabhängig.
• Darüber hinaus ist die Äquivalenzklassenbildung ungeeignet für Komponenten oder Systeme, deren Verhalten von definierten internen Zuständen abhängig ist, beispielsweise Zustände von Geschäftsobjekten oder Systemkomponenten.