Fragenkatalog

• Produkteinsatz

• Produktänderung

• Produktwechsel

• Plan: Planen der nächsten Iteration des SPI-Zyklus basierend auf aktuellen Erfahrungswerten (inkl. Zielsetzung)

• Do: Durchführen der geplanten Aktivität (Task, Projekt, usw.)

• Check: Überprüfung der Produkt- und Prozessergebnisse (z.B. durch Messung)

• Act: Analyse der ERgebnisse als Feedback für den nächsten SPI Zyklus.

Ziel -> Verbesserung der Erfolgsfaktoren, Vermeidung von Wiederholungsfehlern, Beseitigen von Schwachtellen usw.

• Qualität

  z.B.: Anzahl der Fehler in einem Produkt, Termin- und Kostentreue

• Quantität

  z.B.: die Anzahl der implementierten Funktionen, Function Points, Lines of Code (LOC)

• Entwicklungsdauer (z.B.: in Monaten) bzw. Aufwand (z.B.: in Personenmonaten)

  z.B.: “kleine” vs “große” Projekte

• Kosten

• Think

  • Auswahl der zu implementierenden Anforderungen.

  • Spezifikation der Testfälle.

• Red: Implementierung und Ausführung der Testfälle

  • Alle Tests müssen fehlschlagen.

• Green: Implementierung der Komponenten und Klassen und Ausführung der Testfälle

  • Testfall erfolgreich → weiter bei Schritt 4.

  • Testfall schlägt fehlt → weiter bei Schritt 3.

• Refactor: Änderung und Optimierung der Implementierung ohne Änderung der Funktionalität; Ausführung der Testfälle.

  • Testfälle dürfen nicht fehlschlagen.

  • Auswahl der nächsten Anforderung (Schritt 1)

• Card

• Conversation

• Confirmation

Die Karte (Card) ist das physische Medium, das die User- Story beschreibt. Hier werden die Anforderung, ihre Dringlichkeit, die erwartete Dauer für Entwicklung und Test sowie die Abnahmekriterien für diese Story identifiziert. Die Beschreibung muss genau sein, da sie im Product Backlog verwendet wird.

Die Diskussion (Conversation) erklärt, wie die Software genutzt werden wird.

Die Abnahmekriterien, die in der Diskussion festgelegt werden, werden verwendet, um den Abschluss einer User-Story bestätigen (confirm) zu können.

Refactoring ist ein Prozess der Verbesserung der Softwarequalität, bei dem der Code umstrukturiert wird, um die Lesbarkeit, Wartbarkeit oder Effizienz zu verbessern.

Die Schritte umfassen:

1. Identifizierung von Verbesserungsmöglichkeiten

2. Planung der Umstrukturierung

3. Umsetzung der Umstrukturierung

4. Überprüfung der Wirksamkeit der Umstrukturierung

• Planung: Objekt, Prüfziele, Auslösekriterien (Einstiegskriterien), Teilnehmer, Ort, Zeit.

• Vorbesprechung: Vorstellung des Prüfobjekts bei komplexen und neuen Produkten.

• Intensive Einzeldurcharbeitung

• Durchführung: Gemeinsames Lesen, Aufzeichnung von Mängeln;

  (während des Reviews sollen Mängel entdeckt, nicht korrigiert werden)

• Nachbearbeitung: dokumentierte Mängel werden korrigiert

• Bewertung: Korrekturen werden überprüft.

1. Testen zeigt Fehler auf

2. Vollständiges Testen ist nicht möglich

3. Frühzeitiges Testen

4. Fehlerhäufungen beachten

5. Veränderungen statt Wiederholung

6. Testen ist kontextabhängig

7. Trugschluss: Fehlerlose Systeme sind brauchbar

Es zeigt Fehler auf, beweist aber nicht, dass sie nicht mehr vorhanden sind

• Sämtliche Kombinationen von Eingaben, Vorbedingungen und Zuständen zu testen ist nicht umsetzbar/praktikabel

• Stattdessen wird der Testfokus mittels Risiken und Prioritäten festgelegt

• Testaktivitäten sollten so früh wie möglich begonnen

  werden

• Frühzeitig gefundene Fehler sind einfach und günstig zu beheben

Fehler sind nicht gleichmäßig verteilt. Werden in einem Modul einige Fehler gefunden, sind dort meist weitere zu erwarten

Das wiederholte Ausführen von Testfällen wird keine Veränderung bringen (???)

Fehler zu finden und zu beheben garantiert nicht, dass das Produkt den Anforderungen und Bedürfnissen des Benutzers entspricht

Äquivalenzklassenzerlegung:

Zerlegung einer Menge von Daten (Input oder Output) in Untermengen (Klassen), die äquivalente Ergebnisse oder Auswirkungen produzieren. Jede Klasse(nkombination) sollte mindestens einmal getestet werden.

Grenzwertanalyse:

Erweiterung der Äquivalenzklassenzerlegung für bessere Überdeckung. Grenzwerte werden als Klassenrepräsentanten gewählt

Verifikation = Bauen wir das Produkt richtig?

• Umsetzung im Vergleich zur Spezifikation in vorangegangenen Phasen

• Test der Umsetzung gegen die Spezifikation

Validierung = Bauen wir das richtige Produkt?

• Entspricht die Lösung und damit die Spezifikation dem, was der Kunde erwartet?

• Test der Umsetzung gegen die Nutzeranforderungen

• Qualitätsplanung als Teil der Projektplanung

• Herstellen lokaler Standards auf Projekt- und Organisationsebene.

• Review zentraler Projektdokumente

• Organisieren von Reviews: Ausbildung, Planung, Durchführung, Verbesserungsvorschläge.

• Unterstützung bei Personalauswahl und Software-Zukauf.

• Vorbereitung und Auswertung von Produkttests.

• Direkte vs. indirekte Messungen

• Objektive vs. Subjektive Messungen

• Quantitative vs. Qualitative Daten

Objektive Messung:

LoC, Auslieferungsdatum, Aufwand usw.

Subjektive Messung:

Messergebnisse basierend auf der individuellen Sichtweise des Betrachters, z.B. Fragebögen zur Erfassung der Kundenzufriedenheit.

Quantitativ:

Daten als konkrete Zahlenwerte (z.B. für statistische Auswertungen)

Qualitativ:

Visualisierte Informationen (Text, Bilder), z.B. durch Interviews, Interpretationen.

Direkte Messung:

Wertermittlung direkt beim zu untersuchenden Objekt (z.B. Dauer, Aufwand einer Aufgabe)

Indirekte Messung:

Ermittlung von Messwerten aus direkten Messungen (z.B. Effizienz einer Fehlererkennungsmethode = Anzahl der gefundenen Fehler pro Zeiteinheit)

Bei der Inspektion sind die Ziele schwere Defekte im Prüfobjekt zu identifizieren, den Entwicklungsprozess zu verbessern und Metriken zu ermitteln.

Die Teilnehmer sind die Moderatorin, Autor, Gutachterin, Protokollführer, (Vorleser). Die Charakteristika sind eine ausgebildete Moderatorin, das Prüfobjekt wird vom Vorleser Absatz für Absatz vorgetragen. Die Moderatorin gibt die Freigabe für dies.

• Komponententest: Testen von einzelnen Modulen oder Komponenten

• Integrationstest: Testen der Schnittstellen zwischen verschiedenen Komponenten oder Modulen

• Systemtest: Testen des gesamten Systems gegen die Anforderungen

• Abnahmetest: Testen des Systems gegen die Benutzeranforderungen und Abnahme durch den Kunden

• Regressionstest: Wiederholung von Tests, um sicherzustellen, dass Änderungen keine negativen Auswirkungen auf bestehende Funktionen haben

• Last- und Performance-Test: Testen der Leistung und Skalierbarkeit des Systems unter Last

Testautomatisierung = Einsatz von Softwaretools, um Testfälle automatisch auszuführen und Ergebnisse zu überprüfen.

Ziele:

Die Reduzierung von Testaufwand und -kosten, die Erhöhung der Testabdeckung und -effektivität sowie die Verbesserung der Testqualität.

-> schnelles Erkennen von Fehlern

-> leichtes wiederholen von Tests bei Änderungen

Wo eingesetzt?

Testautomatisierung kann in allen Teststufen eingesetzt werden, insbesondere im Komponenten-, Integration- und Regressionstest.

Testen in SCRUM beinhaltet kontinuierliches Testen während des gesamten Entwicklungsprozesses, um sicherzustellen, dass die Anforderungen erfüllt werden und dass das System fehlerfrei ist.

• Der Scrum Prozess sieht keine Tester vor.

• Testen ist Teil der Entwicklung Unit Tests (!)

• Test Driven Development

• Testen geschieht durch den Product Owner / Kunden

• Jeden Sprint Akzeptanzkriterien

Aufgaben eines Testers:

• Statische Tests der Anforderungen / Dokumentation

• Dynamisches Testen (Ausführung von Akzeptanztests)

• Erstellung von Akzeptanztests

• Sicherstellung der Verwaltung von Testfällen im SCM

• Unterstützung bei Unit Tests

• Unterstützung bei test-getriebenem Design

• Test Ansatz

• Test Planung

• Regressionstests (manuell & automatisiert)

• Input während des Meetings (Planung, Sprint Review, etc.)

• Risikoanalyse und –abschätzung

• Schätzung der User Stories

• Demonstration und Unterstützung während des Sprint Reviews

• Tracability von Tests zu User Stories

• Erstellung und Wartung von automatisierten Tests

• Unterstützung bei Akzeptanztests

= Statement Coverage

Ziel:

• Jede Anweisung muss mind. einmal durchlaufen werden.

• Vollständige Anweisungsüberdeckung liegt vor, wenn sämtliche Anweisungen mindestens einmal durchlaufen werden.

  • Zeigt ob toter Code existiert (Anweisungen, die niemals durchlaufen werden können)

• Zu schwaches Kriterium für sinnvolle Testdurchführung

= Branch Coverage (Umfasst Anweisungsüberdeckung vollständig)

Ziel:

• Jede Kante muss mind. einmal durchlaufen werden

• Zeigt nicht ausführbare Programmzweige auf

• Hilft oft durchlaufene Programmteile gezielt zu optimieren

• Im Gegensatz zum Anweisungsüberdeckungstest muss jede Entscheidung mindestens einmal true und false annehmen

Problematik:

• Unzureichender Test von Schleifen

• Komplexe Logik in Statements wird nicht berücksichtigt

• Kunde

• Projektleiter

• Entwicklerteam

Er/Sie hat eine bestimmte Vorstellung davon, was das Produkt leisten soll und welche Anforderungen es erfüllen muss.

-> Wenn der Kunde jedoch nicht genau weiß, was er/sie will oder unklare Anforderungen stellt, kann dies dazu führen, dass das Team in die falsche Richtung arbeitet oder das Produkt nicht den Erwartungen des Kunden entspricht.

Er/Sie hat die Aufgabe, das Projekt zu planen und zu koordinieren und sicherzustellen, dass es innerhalb des Budgets und des Zeitrahmens abgeschlossen wird.

-> Wenn der Projektleiter jedoch nicht genug Ressourcen zur Verfügung hat oder unklare Anforderungen vom Kunden erhält, kann dies dazu führen, dass das Projekt verzögert wird oder nicht den Anforderungen entspricht.

Es ist verantwortlich für die Umsetzung des Produkts und muss sicherstellen, dass es den Anforderungen des Kunden entspricht.

-> Wenn das Team jedoch nicht genug Informationen über die Anforderungen hat oder unklare Anforderungen erhält, kann dies dazu führen, dass das Team Zeit damit verbringt, den Anforderungen auf den Grund zu gehen, anstatt produktiv zu arbeiten.

Die Rolle der QS (Qualitätssicherung) hängt stark vom Vorgehensmodell ab:

• In einem Wasserfallmodell wird die QS oft am Ende des Entwicklungsprozesses durchgeführt, um sicherzustellen, dass das fertige Produkt den Anforderungen entspricht.

• In agilen Vorgehensmodellen wie Scrum wird QS jedoch während des gesamten Entwicklungsprozesses durchgeführt, um sicherzustellen, dass das Produkt kontinuierlich verbessert und den Anforderungen des Kunden entspricht.

• Effizienz:

  Tests können automatisch ausgeführt werden, was Zeit und Ressourcen spart.

• Wiederholbarkeit:

  Tests können automatisch wiederholt werden, um sicherzustellen, dass das Produkt konsistent und zuverlässig ist.

• Skalierbarkeit:

  Automatisierte Tests können leicht auf verschiedene Plattformen und Umgebungen skaliert werden

• Zuverlässigkeit:

  Automatisierte Tests sind genau und reproduzierbar, was dazu beiträgt, Fehler zu identifizieren und zu beheben.

• Früherkennung von Fehlern:

  Durch automatisierte Tests können Fehler frühzeitig im Entwicklungsprozess erkannt und behoben werden, bevor sie zu teuren Problemen werden.

• Dummy

  = Platzhalter ohne Funktionalität

• Stub

  = Ausführbare Implementierung -> Liefert vordefinierte Werte

• Mock

  = Wie Stub - nur werden die parameter die an ein Mock übergeben werden überprüft -> erkennt unerwartete Werte

• Fake

  = Ausführbare Implementierung aber mit Shortcuts (z.B. In memory DB)

• Innere SW Qualität

• Äußere SW Qualität

• Fortschrittskontrolle

• Risiken

• Trends

= eine spezielle Form eines (formalen) Reviews

Ziel:

schwere Defekte im Prüfobjekt, Fehler in Anforderungs-/ Design-Dokumenten finden

Lesetechnik:

Prüfobjekt Absatz für Absatz durchgehen

Vorteile:

• frühes Finden von Fehlern -> billig

• Klärung von Missverständnissen durch gemeinsame Sicht auf das Projekt

• Genaues Durchgehen steigert Verständnis über das geforderte Produkt

Nachteil:

Hohe Kosten durch Personalstunden

Vier Ecken: Qualität, Quantität, Entwicklungsdauer/Aufwand, Kosten

Die Fläche die zur Verfügung steht bleibt gleich - wenn sich eine Zielsetzung ändert, werden die anderen davon beeinflusst