Aufgaben

Die folgenden Übungsaufgaben dienen dazu, den im Buch besprochenen Stoff zu rekapitulieren. Checkfragen für ein Self-Assessment helfen, Situation und Agieren im eigenen Projekt („wie agil sind wir“) kritisch zu hinterfragen und zu beurteilen.

Kapitel 3 – Planung im agilen Projekt

Self-Assessment

  1. Sind Produkt- und Architekturvision für mein Projekt/Produkt explizit formuliert? Wie lauten diese?
  2. Wer hat diese Dokumente erstellt? Wer pflegt diese?
  3. Wie sieht das Product Backlog meines Projekts aus? Wie ist es strukturiert? Wer führt das Product Backlog?
  4. Anhand welcher Kriterien werden die Product Backlog Einträge priorisiert?
  5. Gibt es eine Sprint-übergreifende Planung? Wird eine Story Map eingesetzt? Wie verbindlich ist diese Planung?
  6. Wie sieht das Sprint Backlog meines Projekts aus? Wie ist es strukturiert?
  7. Wer führt das Sprint Backlog? Wer darf Einträge verändern? Ist der Sprint geschützt
  8. Wie sieht die „Definition of Done“ meines Teams aus?
  9. Besitzt mein Team eine „Team Charta“? Wenn nein, wo und durch wen wurden die „Spielregeln“ des Teams festgelegt?
  10. Wie sieht das „Testmanagement“ aus? Gibt es einen Testmanager? Wer erledigt die Aufgaben dieser Rolle?
  11. Welche Teststufen unterscheiden/praktizieren wir?
  12. Wie viele Testfälle sind auf Unit-, Integrations- und Systemtest-Ebene jeweils vorhanden? Wie viele davon liegen automatisiert vor?
  13. Nehmen Sie eine Anforderungen aus ihrem Backlog: erfüllt diese die INVEST Kriterien für eine gute Anforderungsbeschreibung?

Methoden und Techniken

  1. Wer erstellt das Product Backlog und welchen Inhalt hat dieses?
  2. Was ist der Unterschied zwischen Product Backlog und Sprint Backlog?
  3. Wozu dient die Story Map?
  4. Warum muss in der Sprint Planung eine genaue Aufwandschätzung aller für den Sprint vorgesehenen Tasks vorgenommen werden?
  5. Was bedeutet die Formulierung „der Sprint ist geschützt“?
  6. Wie werden Test- und QS-Arbeiten im Sprint Backlog dargestellt?
  7. Wozu dient die „Team Charta“?
  8. Nennen und erläutern Sie die INVEST Kriterien. Wozu dienen sie?
  9. Erläutern Sie das Konzept der Testpyramide.
  10. Erläutern Sie das Konzept der Testquadranten und nennen Sie die in jedem Quadranten enthaltenen Testarten.
  11. Was ist eine Story-Karte?
  12. Was ist „Sprint Null“?

Weiterführende Übungen

  1. Erläutern Sie, in welchen Aspekten die Architekturvision bzw. die Soll-Architektur des Produkts die Sprintplanung beeinflusst.
  2. Formulieren Sie die im Backlog aus Fehler: Referenz nicht gefunden fehlenden Akzeptanzkriterien.
  3. Formulieren Sie Tests, die sie durchführen würden, um festzustellen, ob eine Produktversion diese Akzeptanzkriterien erfüllt?
  4. Auf welcher Ebene im V-Modell ordnen Sie diese Tests ein?

Kapitel 4 – Unit-Tests und Test First

Self-Assessment

  1. Besitzt mein Team automatisierte Unit Tests? Wie viele? Für welche Klassen?
  2. Verwaltet jeder Programmierer seine Tests für sich oder sind alle Unit Tests an zentraler Stelle abgelegt ? Wird ein Unit-Test-Framework eingesetzt?
  3. In welcher Testumgebung werden die Tests ausgeführt? Auf dem Rechner des jeweiligen Programmierers oder auf einem CI-Server? Ist diese Testumgebung definiert und zuverlässig reproduzierbar?
  4. Wann werden diese Unit Tests ausgeführt? Nach Wahl des Programmierers? Im Rahmen von Build-Läufen? Beim Check-in von Code ins Konfigurationsmanagement? Automatisch durch die Continuous-Integration-Umgebung (vgl. Kap. 5)?
  5. Welche Coverage-Kriterien werden verfolgt? Coverage von Klassen (z.B. zu jeder Klasse muss eine Tester-Klasse existieren)? Coverage von Methoden (z.B. mindestens ein Testfall je public-Methode)? Line-Coverage? Zweig-Coverage? Pfad-Coverage? Zustands-bezogene Coverage?
  6. Welche Coverage-Werte sind als Ziel vorgegeben? Wie oft werden diese Werte gemessen? Welche Coverage-Werte werden (jeweils) erreicht?
  7. Welche Werte sind jetzt/heute erreicht? Wo kann das Team diese Werte ablesen? Wo finde ich diese Werte, wenn ich sie jetzt wissen will?
  8. Gibt es Reviews der Testfälle? Regelmäßig? Mit welchen Erkenntnissen? Welche Maßnahmen sind eingeleitet, um die Testabdeckung und/oder die Qualität der Unit Tests weiter zu erhöhen?
  9. Welche Testentwurfstechniken werden (nachvollziehbar) angewendet? Äquivalenzklassenanalyse? Grenzwertanalyse? Zustandsbasiertes Testen? Ist das Team in diesen Techniken geschult?
  10. Wann werden die Tests entworfen? Bevor codiert wird (Test First)? Nachdem die zu testende Unit als Programmcode ausführbar vorliegt? Am Sprint-Ende?
  11. Wer wertet die Testprotokolle bzw Testergebnisse aus und prüft, ob ein Feature „Fertig“ ist ?
  12. Nach welchen „Spielregeln“ wird entschieden, welche Fehler, die in Unit Tests auftreten über das Fehlermanagement verfolgt werden und welche nicht? Wie wird sichergestellt, dass alle in den Unit Tests aufgedeckten Fehler korrigiert werden?
  13. Welche Qualitätssicherungsmaßnahmen außer Unit Tests werden vom Team eingesetzt? Automatische Codeanalysen? Codereviews?
  14. Sind die Qualitätssicherungs- und Testmaßnahmen und ihre Ergebnisse Thema im Daily Scrum und in den Retrospektiven? Was ist die aktuelle Erkenntnis? Welche konkreten Verbesserungsmaßnahmen sind vereinbart? An welchen wird im aktuellen Sprint gearbeitet?

Methoden und Techniken

  1. Aus welchen Abschnitten sollte jeder (Unit-)Testfall bestehen? Erläutern Sie die Aufgabe jedes dieser Abschnitte.
  2. Welche Line Coverage ergibt sich, durch Ablauf des Testfalls test_KitchenLightOn auf Version 2 der Klasse Device im Beispiel <4-2a>?
  3. Ergänzen Sie einen Testfall test_setStatusUnknown, der prüft, ob der Statuswert unknown durch is_validStatus() als gültiger Statuswert klassifiziert wird. Warum ist im Vergleich zu den anderen Testfällen der Tester-Klasse ein zusätzlicher Testschritt nötig?
  4. Frage zu <Abb. 4-1>: Wenn die Unit Tests der Klasse 100% Line Coverage auf Codeebene erreichen, werden alle Klassenmethoden mindestens einmal aufgerufen. Darf daraus geschlossen werden, dass die Tests im Zustandsmodell auch 100% Kanten-Coverage erreichen? Begründung?
  5. Über eine Methode dim($power) soll die Helligkeit einer angeschlossenen Lampe von 0% bis 100% eingestellt werden können. Die Methode besitzt als Parameter einen Integerwert. Welche Äquivalenzklassen und Grenzwerte sollte der Tester in seinen Testfällen verwenden? Wie viele Testfälle ergeben sich? Schreiben Sie geeignete Testfälle (unter Nutzung o.g. Vier-Abschnitte-Schema) auf.
  6. Begründen Sie, warum der Einsatz von Test First zu besseren APIs und verbesserter Testbarkeit führt.
  7. Welche Probleme können bei der Einführung von Test First auftreten und wie kann der Scrum Master dem begegnen?

Weiterführende Übungen

  1. Korrigieren Sie die Methode set_dimLevel() der Klasse Dimmer, so dass die Testfälle in Fallbeispiel <4b> erfolgreich durchlaufen.
  2. Zerlegen Sie unter Anwendung der Methode von [Bashir 99] die Dimmer-Klasse in ‚Slices‘. Welche Slices erhalten Sie? Welche Testfallsequenzen sollten demnach für Dimmer ausgeführt werden?
  3. dim(‚0%‘) soll bedeuten, dass das gesteuerte Gerät in den Zustand ‚off‘ wechselt. Formulieren Sie einen Testfall, der dieses Verhalten spezifiziert.
  4. Ein dim-Befehl soll im Zustand unknown oder im Zustand off keine Wirkung haben. Formulieren Sie Testfälle, die dieses Verhalten spezifizieren.
  5. Aufgrund dieser zusätzlichen Anforderungen wird der Code der Klasse Dimmer ergänzt zu einer neuen Version v3. Ändern sich dadurch die o.g. ‚Slices‘? Wenn ja, welche Auswirkung hat das auf die nötigen Testfallsequenzen?
  6. Das eHome-System soll Geräte auch zeitgesteuert ein- und ausschalten können. Dies soll mit Hilfe einer neuen Klasse Timer realisiert werden. Da das Team Test First anwendet, benötigt es zuerst die passenden Unit-Testfälle für diese neue Klasse. Helfen Sie dem Team und schreiben Sie Unit-Testfälle, die folgendes Verhalten eines einfachen Timer spezifizieren:
    Mit set_interval() kann die Zeit in Sekunden bis zum Ablauf des Timers eingestellt werden. start() startet den Timer; stop() stoppt ihn. is_finished()1 gibt TRUE zurück, wenn der Timer abgelaufen ist, ansonsten FALSE.
    Welche Lücken in der Spezifikation fallen Ihnen auf?

Kapitel 5 – Integrationstests und Continuous Integration

Self-Assessment

  1. Besitzt mein Team automatisierte Integrationstests? Wie viele? Wie viele in Relation zu den Unit-Testfälllen?
  2. Wie und wo ist die gewünschte Systemarchitektur definiert bzw. dokumentiert? Prüfen die Integrationstestfälle „gegen“ diese Sollarchitektur?
  3. Gibt es Reviews, in denen Architektur und Testfälle gegeneinander abgeglichen werden? Regelmäßig? Mit welchen Erkenntnissen?
  4. Für welche Schnittstellen gibt es Integrationstests? Welche Schnittstellenabdeckung (Coverage) wird erreicht?
  5. Welche Coverage-Werte sind als Ziel vorgegeben? Wie oft werden diese Werte gemessen?
  6. Welche Werte sind jetzt/heute erreicht? Wo kann das Team diese Werte ablesen? Wo finde ich diese Werte, wenn ich sie jetzt wissen will?
  7. Welche Maßnahmen sind eingeleitet, um die Testabdeckung und/oder die Qualität der Integrationstests weiter zu erhöhen?
  8. Werden Schnittstellenmonitore eingesetzt? Für welche Schnittstellen?
  9. Existiert ein automatisierter CI-Prozess? Wie sieht dieser aus?
  10. Wann werden die Integrationstests ausgeführt? Sind sie in die CI-Umgebung eingebunden?
  11. In welcher Testumgebung werden die Integrationstests ausgeführt? Ist diese Testumgebung definiert und zuverlässig reproduzierbar?
  12. Wie sind die Laufzeiten der Integrationstests im Vergleich zu den Unit Tests?
  13. Wann werden die Integrationstests entworfen? Auf Basis der Architekturbeschreibung, bevor codiert wird (Test First), wenn die zu integrierenden Bausteine als Programmcode ausführbar vorliegen, oder am Sprint-Ende?
  14. Werden Integrationsaufgaben im Sprint-Backlog als Tasks explizit geplant?
  15. Sind Integrationstests Teil der „Definition of Done“?
  16. Welche Testergebnisse zeigen die Integrationstests jetzt/heute?
  17. Wie viele und welche Fehler finden die Integrationstests im Vergleich zu den Unit Tests?
  18. Wie erfolgen das Fehlermanagement und das Bugfixing, wenn Schnittstellen zu Teilsystemen fehlerhaft sind, die von anderen bzw. externen Teams verantwortet werden?
  19. Wie werden Absprachen über solche teamübergreifende Schnittstellen festgehalten? Ist das Thema in den „Scrum of Scrums“?
  20. Welche weitere architektur- und schnittstellen­bezogene Prüfungen werden vom Team eingesetzt? Architekturreviews, automatische Analysen oder Validierungen von Schnittstellen oder Daten?
  21. Sind der CI-Prozess und seine Ergebnisse Thema im Daily Scrum?
  22. Sind Möglichkeiten zu dessen Verbesserung Thema in Retrospektiven? Was ist die aktuelle Erkenntnis? Welche konkreten Verbesserungsmaßnahmen sind vereinbart? An welchen wird im aktuellen Sprint gearbeitet?
  23. Falls mehr als ein Scrum-Team am Produkt arbeiten: Nutzen sie einen gemeinsamen CI-Prozess? Wer verantwortet diesen? Wem „gehören“ die CI-Werkzeuge und die Hardware? Ist das Thema in den Scrum of Scrums?

Methoden und Techniken

  1. Welche typischen Integrationsfehler können vorkommen? Erläutern Sie die jeweiligen Symptome und Ursachen.
  2. Wie können Integrationstestfälle systematisch hergeleitet werden? Nennen und erläutern Sie die nötigen Schritte.
  3. Erläutern Sie die Gemeinsamkeiten und Unterschiede zwischen einem Unit-Testfall und einem Integrationstestfall.
  4. Wann sind zwei Softwarebausteine voneinander abhängig? Wie unterscheiden sich explizite und implizite Abhängigkeit?
  5. Erläutern Sie den Begriff „Testbarkeit“.
  6. Warum und wie beeinflusst die Testbarkeit einer Schnittstelle den Aufwand der zugehörigen Integrationstests.
  7. Warum kommt bei objektorientierten Systemen den Integrationstests eine erhöhte Bedeutung zu?
  8. In welcher Form wirkt das iterative Vorgehen im Scrum-Projekt als zusätzlicher Treiber für den Integrationstestaufwand ?
  9. Warum kann ein Refactoring der Systemarchitektur den Integrationstestaufwand ggf. verringern ?
  10. Nennen Sie die verschiedenen Varianten der Klassenintegration.
  11. Was versteht man unter Teilsystemintegration?
  12. Was versteht man unter Systemintegration?
  13. Erläutern Sie, wie die Sprint-Planung die Integrationsreihenfolge beeinflusst. Welche Integrationsstrategie ergibt sich deshalb im Scrum-Projekt?
  14. Welchen Elemente und Prozessschritte gehören zu einem CI-Prozess?
  15. „Ohne CI kein Scrum!“. Begründen Sie diese Aussage.
  16. Welche Schritte sind vorzusehen, wenn ein CI-Prozess eingeführt wird?
  17. Welche Ansatzpunkte gibt es, um den CI-Prozess kontinuierlich zu optimieren

Weiterführende Übungen

  1. Erläutern Sie, welche Art Integrationsfehler durch syntaktische Prüfungen (zur Compilezeit) aufgedeckt werden können und welche nicht.
  2. Welche Integrationsfehler können nur bei asynchron gekoppelten Bausteinen auftreten? Warum?
  3. Wie wirkt es sich aus, wenn ein Baustein1 fälschlicherweise synchron statt asynchron gekoppelt wird? Erläutern Sie das unterschiedliche Verhalten am Beispiel eines eHome-Rollosteuerungsbefehls. Wie kann ein Testfall aussehen, der prüft, ob der eHome-Rollosteuerungsbefehl tatsächlich asynchron abgearbeitet wird?
  4. Softwarebausteine können implizit/indirekt voneinander abhängen. Erläutern Sie typische Quellen für solche indirekten Abhängigkeiten.
  5. Erläutern Sie, wie implizite Abhängigkeit in explizite Abhängigkeit transformiert werden kann. Geben Sie ein Beispiel an.
  6. Angenommen, drei Bausteine besitzen eine Datei als gemeinsame Ressource: Erläutern Sie, warum Negativtests bzw. Robustheitstests für diese Bausteine einen höheren Aufwand verursachen als bei Kapselung der Datei in einen zentralen Service. Warum ist das bei Positivtestfällen oder Happy-Path-Tests nicht so?

Kapitel 6 – Systemtests und Test nonstop

Self-Assessment

  1. Differenziert mein Team zwischen Unit Tests, Integrations- und Systemtests?
  2. Wie viele Testfälle gibt es auf welcher der drei Ebenen? Wie hoch ist jeweils der Automatisierungsgrad? Welche und wieviele Testfälle sind im CI eingebunden
  3. Gibt es verschiedene Testumgebungen?
  4. Wann führt das Team Systemtests durch? In einem Systemtest-Sprint, am Sprintende oder nonstop?
  5. Wie werden Systemtests automatisiert? Mittels aufgezeichneter GUI-Tests (Capture & Replay) oder mittels Scripting?
  6. Wenn Scripting verwendet wird: Nutzt das Team einen Schlüsselwortansatz oder einen DSL-Ansatz?
  7. Wann werden die Systemtestfälle erstellt? Mit Test First vor der Implementierung des zu testenden Features? Oder erst wenn das Feature im Build lauffähig vorliegt?
  8. Welche nichtfunktionalen Tests gibt es? Sind dabei alle Testarten aus ISO 25010 angemessen abgedeckt?
  9. Wird zwischen Systemtests und Akzeptanztests differenziert?
  10. Wer entscheidet, welcher Build zum Releasekandidaten wird?
  11. Wann wird ein externes Release erstellt? Gibt es auch hierfür einen festen Rhythmus?
  12. Wie ist die Rolle des Testmanagers im Team verankert? Gibt es einen Mitarbeiter, der die Rolle ausfüllt? Explizit? Implizit? Oder ist die Rolle verwaist?

Methoden und Techniken

  1. Welche Schnittstellen im eHome-Architekturdiagramm (Abb. <3-1>) verwenden die eHome-Systemtests aus den Beispielen dieses Kapitels?
  2. Formulieren Sie nach dem Muster aus Beispiel <y – Schlüsselwortmethode> ein Systemtestszenario für Use Case UC-5 aus Beispiel <x>. (Hinweis: Ein Schaltprogramm ist eine Liste von Schaltkommandos mit einer globalen Datum/Uhrzeitangabe, das den Zeitpunkt bestimmt, wann das Schaltprogramm starten soll.)
  3. Formulieren Sie Ihr o.g. Systemtestszenario als datengetriebenen Test und notieren Sie die Testdaten als Tabelle. Wieviele Testfälle haben Sie für UC-5 damit definiert? Genügt das? Benötigen Sie weitere?
  4. Welche zusätzlichen Testfälle benötigen Sie, wenn auch ein erneuter Programmstartzeitpunkt relativ zum ersten Start angegeben werden kann (z.B. „alle zwei Stunden“, „täglich“, „alle drei Tage“ etc.).
  5. Welche weiteren Einstellmöglichkeiten des Programmstartzeitpunkts würden Sie sich wünschen? Formulieren Sie diese im Test-First-Stil durch passende Testfälle.
  6. Welche unterschiedlichen Testziele verfolgen Systemtests in Abgrenzung zu Systemintegrationstests?

Weiterführende Übungen

  1. Wie ändert sich die Aussage Ihres in Frage 2. oben entworfenen Testszenarios, wenn es über unterschiedliche Testschnittstellen abläuft (z.B. Anwender/GUI vs. GUI/Controller)?
  2. Um Aufwand zu sparen, wollen Sie nur eine der beiden Testschnittstellen durch Ihre Systemtests abdecken. Welche wählen Sie? Warum?
  3. Wenn Sie sich Ihre Tests des Features „Schaltprogramm“ ansehen: Welche davon könnten Sie in den Integrationstest oder Unit Test vorverlagern? Skizzieren Sie (in einer Tabelle ähnlich Bsp <xx-3>) wie Ihre Schlüsselworte zu Unit-Test-Aufrufen einer Klasse „Schaltprogramm“ korrespondieren (Hinweis: Überlegen Sie sich zuerst, wie das API der „Schaltprogramm“-Klasse aussehen sollte).
  4. Betrachten Sie Beispiel xx-2. Wie sollte das eHome- System reagieren, wenn ein der Kommandosyntax widersprechender „Satz“ empfangen wird? Formulieren Sie das gewünschte Systemverhalten durch Testfälle. Welches Feedback geben Sie dem Entwickler der Kommandoschnittstelle?
  5. Wie sollte sich das System verhalten, wenn der Befehl syntaktisch korrekt ist, aber nicht existierende Orte oder Geräte referenziert? Betrachten Sie das am Beispiel des Befehls „Erdgeschoss Licht Keller an“. Formulieren Sie dabei Testfälle für ein „komfortorientiertes“ Verhalten (die Geräte schalten, die vermutlich gemeint waren) und alternativ für ein „sicherheitorientiertes“ Verhalten (im Zweifel nichts schalten oder nachfragen).

Kapitel 7 – QM und QS agil

Self-Assessment

  1. Wie beurteilen Sie das QM-System ihres Unternehmens? Stimmen die Regelungen mit der Unternehmenspraxis im wesentlichen überein? Oder sind sie eher eine „Parallelwelt“.
  2. Sind die Regelungen aktuell? Von wann datiert das letzte update des Systems?
  3. Finden Sie ihre eigenen Aufgaben und ihren Zuständigkeitsbereich angemessen abgebildet? Befolgen Sie persönlich die Regelungen, die für Ihren Zuständigkeitsbereich gelten?
  4. Kennen Sie alle QM-Dokumente, die ihren Arbeitsbereich betreffen? Wie lange benötigen Sie, um ein bestimmtes Dokument zu finden und nachzuschlagen?
  5. Wie werden geänderte oder neue Prozesse eingeführt? Gibt es Informationsveranstaltungen oder Schulungen?
  6. Wie ist der Softwareentwicklungsprozess definiert? In welcher Phase dieses Prozesses befinden sie sich aktuell mit Ihrem eigenen Projekt? Anhand welcher Kriterien erkennen Sie, dass diese Phase beendet werden kann.
  7. Sofern Sie an einem Audit teilnahmen: welche Befunde gab es und haben Sie seither Korrekturmaßnahmen umgesetzt?
  8. Wie beurteilen Sie die Zusammenarbeit ihrer Abteilung/ihres Teams mit dem QM-Stab? Wo würden „agile Vorgehensweisen“ helfen?
  9. Falls (einige) Teams (schon) agil arbeiten: wie arbeiten die Scrum Master mit dem QM-Stab zusammen? Wird umgesetzt, was in den Retrospektiven angesprochen wird? Was könnte verbessert werden?
  10. Welche analytischen QS-Maßnahmen außer „Testen“ und welche Techniken im Sinne „konstruktiver QS“ kommen in Ihrem Projekt zum Einsatz? Welche Maßnahmen oder Techniken werden nicht genutzt, obwohl sie sinnvoll wären? Aus welchen Gründen?
  11. Falls (einige) Teams (schon) agil arbeiten: wie ist dort das „Testen“ organisiert? Wie gut erfüllen/beherrschen diese Teams die „Erfogsfaktoren für agiles Testen“ ?
  12. Wie sieht der aktuelle Testplan ihres Projekts aus? Können Sie diesem Plan entnehmen, welche Testaufgaben heute oder kommende Woche zu erledigen sind? Sind das die Aufgaben, die tatsächlich erledigt werden? Werden damit rechtzeitig die „richtigen“ Fehler gefunden?

Methoden und Techniken

  1. Erläutern Sie den Begriff „PDCA-Zyklus“.
  2. Betrachten Sie den Projektplan in Abbildung <2-x>. Welche PDCA-Zyklen lassen sich hier identifizieren?
  3. Betrachten Sie den Scrum-Prozess in Abbildung <3-x>. Welche PDCA-Zyklen lassen sich hier identifizieren?
  4. Erläutern Sie den Unterschied zwischen einer „Team Charta“ und einer Beschreibung des agilen Entwicklungsprozesses im QM-System.
  5. Erklären Sie die beiden Scrum Werkzeuge „Sprint Review“ und „Sprint Retrospektive“. Welche PDCA-Zyklen werden durch diese Instrumente jeweils „geschlossen“? Listen Sie die jeweils zugehörigen „PDC-Instrumente“ auf.
  6. Was versteht man unter „Traceability“? Warum fordern einschlägige Normen, dass bei der Entwicklung von Software für sicherheitskritische Produkte Traceability gegeben sein muss?
  7. Nennen Sie Vor- und Nachteile einer organisatorisch/personellen Trennung zwischen Entwicklern und Prüfern/Testern.
  8. Erklären Sie das agile Prinzip „Überprüfung und Anpassung“. Erläutern Sie Gemeinsamkeiten und Unterschiede zum PDCA-Zyklus.
  9. Nennen Sie Vor- und Nachteile der Zusammenarbeit im interdisziplinären Team. Welche Risiken sind damit verbunden?
  10. Nennen und erläutern Sie die Erfolgsfaktoren für agiles Testen.

Weiterführende Übungen

  1. Unabhängig davon, ob Sie klassisch oder agil arbeiten: Beschreiben Sie Ihren Softwareentwicklungsprozess auf max. einer DIN-A4 Seite.
  2. Wählen Sie ein zweites Softwareprojekt oder -Team in Ihrem Umfeld. Wo weicht deren Vorgehen von Ihrem (in der vorstehenden Übung) beschriebenen Vorgehen ab? Verallgemeinern Sie „Ihre“ Prozessbeschreibung so, dass beide Ausprägungen gleich gut erfasst werden.
  3. Sofern Ihr Softwareentwicklungsprozess agil ist: Beschreiben Sie im Stil einer Team Charta (vgl. Abschnitt <3.6>), wie das „Sprint Planungs Meeting“ und die „Aufwandschätzung“ bei Ihnen funktionieren. Trifft diese Beschreibung nur für Ihr Team zu oder auch für andere Teams?