Agile Testing

Der agile Weg zur Qualität
 
 
Hanser, Carl (Verlag)
  • 2. Auflage
  • |
  • erschienen am 6. November 2017
  • |
  • 271 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-45298-5 (ISBN)
 
Der Trend zu agilen Vorgehen ist ungebrochen

Dieser Trend geht auch am Softwaretest nicht spurlos vorüber. Nachdem die Bedeutung des Tests in agilen Projekten unumstritten ist, treten jetzt vor allem die Professionalisierung und die Integration der einzelnen Mitarbeiter in den rollenübergreifenden Tätigkeiten des agilen Vorgehens in den Vordergrund.

Die klassischen Rollenbilder des Tests verschwimmen und gehen ineinander über. Die Eigenverantwortung der Tester steigt. Für den klassischen Tester bedeutet dies eine Bereicherung und Aufwertung seiner Rolle, da er auch Aufgaben und Tätigkeiten anderer Professionen übernimmt.

- Der Stellenwert des Teams
- Die Crux mit den Werkzeugen in agilen Projekten
- Die sieben schlechtesten Ideen für die Testautomatisierung
- Testmethoden im agilen Umfeld
- Tester: Generalist vs. Spezialist?

Welches sind nun aber die Aufgaben des Softwaretests in agilen Projekten? Wie sind diese in unterschiedlichen agilen Vorgehensweisen - wie etwa Scrum oder Kanban - zu organisieren? Welche Bedeutung haben Testwerkzeuge in diesem Kontext? Wie grenzen sich die Verantwortlichkeiten gegeneinander ab oder wirken synergetisch zusammen?

Auf diese sehr konkreten Fragen, die sich im operativen Projektgeschehen immer wieder stellen, liefert dieses Buch mögliche Antworten, ergänzt durch bewährte Ansätze aus der Praxis.
2., überarbeitete und erweiterte Auflage
  • Deutsch
  • München
  • |
  • Deutschland
  • 11,72 MB
978-3-446-45298-5 (9783446452985)
3446452982 (3446452982)
http://dx.doi.org/10.3139/9783446452985
weitere Ausgaben werden ermittelt
Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl und Siegfried Tanczos sind seit langer Zeit im Bereich des Software-Tests tätig. In den letzten Jahren hatten sie die Chance, immer mehr agile Projekte aus den unterschiedlichsten Branchen kennenzulernen und zu begleiten. So treffen hier Erfahrungen aus der Telekommunikations-, Medizintechnik-, Banken-, Energieversorger- und Luftfahrtbranche aufeinander.
1 - Inhalt [Seite 6]
2 - Geleitwort [Seite 11]
3 - Vorwort [Seite 18]
4 - Praxisbeispiele [Seite 20]
5 - Die Autoren [Seite 21]
6 - 1 Agil - ein kultureller Wandel [Seite 26]
6.1 - 1.1 Der Weg zur agilen Entwicklung [Seite 26]
6.2 - 1.2 Gründe für eine agile Entwicklung [Seite 29]
6.3 - 1.3 Die Bedeutung des Agilen Manifests für den Software-Test [Seite 32]
6.4 - 1.4 Agil setzt Kulturwandel bei den Anwendern voraus [Seite 35]
6.5 - 1.5 Konsequenzen der agilen Entwicklung für die Software-Qualitätssicherung [Seite 37]
6.5.1 - 1.5.1 Räumliche Konsequenzen [Seite 37]
6.5.2 - 1.5.2 Zeitliche Konsequenzen [Seite 38]
7 - 2 Agile Vorgehensmodelle und deren Sicht auf Qualitätssicherung [Seite 40]
7.1 - 2.1 Herausforderungen in der Qualitätssicherung [Seite 41]
7.1.1 - 2.1.1 Qualität und Termin [Seite 41]
7.1.2 - 2.1.2 Qualität und Budget [Seite 42]
7.1.3 - 2.1.3 Der Stellenwert des Software-Tests [Seite 43]
7.1.4 - 2.1.4 Fehler aus Vorprojekten (Technical Debt) [Seite 45]
7.1.5 - 2.1.5 Testautomatisierung [Seite 46]
7.1.6 - 2.1.6 Hierarchische Denkweise [Seite 47]
7.2 - 2.2 Der Stellenwert des Teams [Seite 47]
7.3 - 2.3 Audits zur Qualitätssicherung in agilen Projekten [Seite 49]
7.3.1 - 2.3.1 Scrum [Seite 49]
7.3.1.1 - 2.3.1.1 Sprint Review Meeting [Seite 51]
7.3.1.2 - 2.3.1.2 Sprint Retrospektive [Seite 52]
7.3.2 - 2.3.2 Kanban [Seite 56]
7.3.2.1 - 2.3.2.1 Kaizen - Continuous Improvement [Seite 57]
7.4 - 2.4 Continuous Integration [Seite 58]
7.5 - 2.5 Lean Software Development [Seite 59]
8 - 3 Die Organisation des Software-Tests in agilen Projekten [Seite 62]
8.1 - 3.1 Die Platzierung von Tests in agilen Projekten [Seite 63]
8.1.1 - 3.1.1 Der fundamentale Testprozess des ISTQB [Seite 63]
8.1.1.1 - 3.1.1.1 Testplanung und -steuerung [Seite 63]
8.1.1.2 - 3.1.1.2 Testanalyse und Testentwurf [Seite 66]
8.1.1.3 - 3.1.1.3 Testrealisierung und Testdurchführung [Seite 67]
8.1.1.4 - 3.1.1.4 Bewertung von Endekriterien und Bericht [Seite 68]
8.1.1.5 - 3.1.1.5 Abschluss der Testaktivitäten [Seite 69]
8.1.2 - 3.1.2 Welcher Test wofür - die vier Testquadranten agilen Testens [Seite 71]
8.1.2.1 - 3.1.2.1 Erster Quadrant: technisch orientiert und teamunterstützend [Seite 72]
8.1.2.2 - 3.1.2.2 Zweiter Quadrant: fachlich orientiert und teamunterstützend [Seite 75]
8.1.2.3 - 3.1.2.3 Dritter Quadrant: fachlich orientiert, aber produkthinterfragend [Seite 78]
8.1.2.4 - 3.1.2.4 Vierter Quadrant: technisch orientiert aber produkthinterfragend [Seite 79]
8.1.2.5 - 3.1.2.5 Der Kontext [Seite 81]
8.1.3 - 3.1.3 Tipps für den Software-Test aus agiler Perspektive [Seite 82]
8.1.4 - 3.1.4 Agil im Großen mit SAFe oder LeSS [Seite 85]
8.1.4.1 - 3.1.4.1 Testen mit SAFe [Seite 85]
8.1.4.2 - 3.1.4.2 Testen mit LeSS [Seite 88]
8.1.5 - 3.1.5 Skalierbare Organisation agiler Teams [Seite 90]
8.2 - 3.2 Praxisbeispiele [Seite 93]
8.2.1 - 3.2.1 Die Rolle des Testers und ihre Veränderung im Laufe der Zeit zum Quality Specialist bei otto.de - ein Erfahrungsbericht [Seite 93]
8.2.2 - 3.2.2 Abnahmetest als eigenes Scrum-Projekt/-Team [Seite 97]
8.2.3 - 3.2.3 Test Competence Center für agile Projekte [Seite 98]
8.2.4 - 3.2.4 Team im Healthcare-Bereich nutzt V-Modell [Seite 99]
9 - 4 Die Rolle des Testers in agilen Projekten [Seite 102]
9.1 - 4.1 Generalist vs. Spezialist [Seite 102]
9.2 - 4.2 Der Weg vom zentralen Testcenter in das agile Team [Seite 104]
9.2.1 - 4.2.1 Varianten der Testereinbindung in traditionellen Teams [Seite 105]
9.2.2 - 4.2.2 Varianten der Testereinbindung in agile Teams [Seite 106]
9.2.2.1 - 4.2.2.1 Die Umstellung von der traditionellen auf die agile Welt [Seite 107]
9.2.2.2 - 4.2.2.2 Steigerung von Effizienz und Effektivität [Seite 108]
9.2.2.3 - 4.2.2.3 Teamzusammenstellung [Seite 109]
9.3 - 4.3 Herausforderungen der Tester im Team [Seite 115]
9.3.1 - 4.3.1 Die Tester im agilen Team [Seite 115]
9.3.1.1 - 4.3.1.1 Der Quality Coach [Seite 116]
9.3.1.2 - 4.3.1.2 Aufgaben der agilen Tester [Seite 116]
9.3.2 - 4.3.2 Rechtzeitige Problemaufdeckung [Seite 118]
9.3.3 - 4.3.3 Die Entstehung technischer Schulden [Seite 120]
9.4 - 4.4 Teams und Tester im Kampf gegen "technical debt" [Seite 121]
9.4.1 - 4.4.1 Was ist "technical debt"? [Seite 121]
9.4.2 - 4.4.2 Der Umgang mit technischen Schulden [Seite 123]
9.5 - 4.5 Erfahrungsbericht: Quality Specialist bei otto.de [Seite 125]
9.5.1 - 4.5.1 Wir agieren als Quality-Coach des Teams [Seite 125]
9.5.2 - 4.5.2 Wir begleiten den kompletten Story-Lifecycle [Seite 126]
9.5.3 - 4.5.3 Wir betreiben Continuous Delivery/Continuous Deployment [Seite 126]
9.5.4 - 4.5.4 Wir balancieren die unterschiedlichen Testarten der Testpyramide [Seite 127]
9.5.5 - 4.5.5 Wir helfen dem Team, die richtigen Methoden für hohe Qualität einzusetzen [Seite 127]
9.5.6 - 4.5.6 Wir sind im Pairing aktiv [Seite 128]
9.5.7 - 4.5.7 Wir vertreten unterschiedliche Perspektiven [Seite 128]
9.5.8 - 4.5.8 Wir sind Kommunikationstalente [Seite 129]
9.5.9 - 4.5.9 Wir sind Quality Specialists [Seite 129]
9.6 - 4.6 Zu alt für agil? Die mentale Herausforderung [Seite 130]
9.6.1 - 4.6.1 Ausgangslage [Seite 130]
9.6.2 - 4.6.2 Was führt zur Aussage "Agil ist etwas für junge Leute"? [Seite 131]
9.6.2.1 - 4.6.2.1 Kreativität und Flexibilität [Seite 131]
9.6.2.2 - 4.6.2.2 Verhaftet in alten Denkmustern [Seite 131]
9.6.2.3 - 4.6.2.3 Trägheit, fehlende Beweglichkeit [Seite 132]
9.6.2.4 - 4.6.2.4 Arbeitsumfeld [Seite 132]
9.6.2.5 - 4.6.2.5 Vorteile der Jugend [Seite 133]
9.6.2.6 - 4.6.2.6 Stärken der Senior-Tester/Senior-Manager [Seite 133]
9.7 - 4.7 Hilfreiche Tipps vom Markt [Seite 134]
10 - 5 Agiles Testmanagement, -methoden und -techniken [Seite 136]
10.1 - 5.1 Testmanagement [Seite 137]
10.1.1 - 5.1.1 Testplanung im traditionellen Umfeld [Seite 137]
10.1.2 - 5.1.2 Testplanung im agilen Umfeld [Seite 139]
10.1.3 - 5.1.3 Testkonzept [Seite 141]
10.1.4 - 5.1.4 Testaktivitäten in Iteration Zero - Initialisierungs-Sprint [Seite 144]
10.1.5 - 5.1.5 Externe Unterstützung der Testplanung [Seite 145]
10.1.6 - 5.1.6 Testschätzung [Seite 145]
10.1.7 - 5.1.7 Testorganisation [Seite 147]
10.1.8 - 5.1.8 Testerstellung, Durchführung und Release [Seite 148]
10.2 - 5.2 Testmethoden im agilen Umfeld [Seite 149]
10.2.1 - 5.2.1 Risikobasiertes und valuebasiertes Testen [Seite 150]
10.2.2 - 5.2.2 Explorativer Test [Seite 153]
10.2.3 - 5.2.3 Session-basiertes Testen [Seite 154]
10.2.4 - 5.2.4 Abnahmetestgetriebene Entwicklung [Seite 157]
10.2.5 - 5.2.5 Testautomatisierung [Seite 157]
10.3 - 5.3 Wesentliche Einflussfaktoren auf den Test [Seite 158]
10.3.1 - 5.3.1 Continuous Integration (CI) [Seite 158]
10.3.2 - 5.3.2 Automatisiertes Konfigurationsmanagement [Seite 160]
10.4 - 5.4 Die besonderen Herausforderungen beim Test von IoT [Seite 161]
10.4.1 - 5.4.1 Was ist das Internet of Things? [Seite 161]
10.4.2 - 5.4.2 Die Herausforderung für agile Teams im Test [Seite 163]
11 - 6 Agile Testdokumentation [Seite 166]
11.1 - 6.1 Die Rolle der Dokumentation in der Software-Entwicklung [Seite 167]
11.2 - 6.2 Der Nutzen der Dokumentation [Seite 168]
11.3 - 6.3 Dokumentationsarten [Seite 171]
11.3.1 - 6.3.1 Anforderungsdokumentation [Seite 172]
11.3.2 - 6.3.2 Codedokumentation [Seite 173]
11.3.3 - 6.3.3 Testdokumentation [Seite 174]
11.3.3.1 - 6.3.3.1 Testfallbeschreibung [Seite 174]
11.3.3.2 - 6.3.3.2 Testdurchführung [Seite 175]
11.3.3.3 - 6.3.3.3 Testüberdeckung [Seite 175]
11.3.3.4 - 6.3.3.4 Fehlerdokumentation [Seite 176]
11.3.4 - 6.3.4 Benutzerdokumentation [Seite 177]
11.4 - 6.4 Der Tester als Dokumentierer [Seite 179]
11.5 - 6.5 Stellenwert der Dokumentation im agilen Test [Seite 179]
12 - 7 Agile Testautomatisierung [Seite 182]
12.1 - 7.1 Die Crux mit den Werkzeugen in agilen Projekten [Seite 182]
12.2 - 7.2 Testautomatisierung - wie geht man es an? [Seite 184]
12.3 - 7.3 Testautomatisierung mit zunehmender Integration der Software [Seite 186]
12.3.1 - 7.3.1 Unit Test bzw. Komponententest [Seite 186]
12.3.2 - 7.3.2 Komponentenintegrationstest [Seite 187]
12.3.3 - 7.3.3 Systemtest [Seite 187]
12.3.4 - 7.3.4 Systemintegrationstest [Seite 187]
12.4 - 7.4 xUnit-Frameworks [Seite 188]
12.5 - 7.5 Einsatz von Platzhaltern [Seite 194]
12.6 - 7.6 Integrationsserver [Seite 195]
12.7 - 7.7 Testautomatisierung im fachlich orientierten Test [Seite 197]
12.7.1 - 7.7.1 Ein Framework - wozu? [Seite 199]
12.7.2 - 7.7.2 Agile versus klassische Automatisierung von Benutzereingaben [Seite 201]
12.7.2.1 - 7.7.2.1 Agile Testautomatisierung [Seite 201]
12.7.2.2 - 7.7.2.2 Klassische Testautomatisierung [Seite 202]
12.7.3 - 7.7.3 Ein typisches Beispiel: FitNesse und Selenium [Seite 204]
12.7.4 - 7.7.4 Behavior Driven Development mit Cucumber und Gherkin [Seite 208]
12.8 - 7.8 Testautomatisierung im Last- und Performance-Test [Seite 211]
12.9 - 7.9 Die sieben schlechtesten Ideen für die Testautomatisierung [Seite 211]
12.9.1 - 7.9.1 Den Erfolg nach wenigen Sprints erwarten [Seite 212]
12.9.2 - 7.9.2 Testwerkzeugen blind vertrauen [Seite 212]
12.9.3 - 7.9.3 Schreiben der Testskripts als Nebenbeschäftigung ansehen [Seite 213]
12.9.4 - 7.9.4 Testdaten irgendwo in Testfällen vergraben [Seite 213]
12.9.5 - 7.9.5 Testautomatisierung nur mit Benutzeroberflächen in Verbindung bringen [Seite 214]
12.9.6 - 7.9.6 Soll-Ist-Vergleich unterschätzen [Seite 214]
12.9.7 - 7.9.7 (Un-)Testbarkeit der Applikation einfach hinnehmen [Seite 215]
13 - 8 Werkzeugeinsatz in agilen Projekten [Seite 216]
13.1 - 8.1 Projektmanagement [Seite 217]
13.1.1 - 8.1.1 CA Agile Central [Seite 219]
13.2 - 8.2 Anforderungsmanagement [Seite 220]
13.2.1 - 8.2.1 Polarion QA/ALM [Seite 223]
13.3 - 8.3 Fehlermanagement [Seite 226]
13.3.1 - 8.3.1 The Bug Genie [Seite 229]
13.3.2 - 8.3.2 Atlassian JIRA [Seite 231]
13.4 - 8.4 Testplanung und -steuerung [Seite 233]
13.4.1 - 8.4.1 Atlassian JIRA [Seite 235]
13.5 - 8.5 Testanalyse und Testentwurf [Seite 238]
13.5.1 - 8.5.1 Risikobasiertes Testen in der TOSCA-Testsuite [Seite 239]
13.6 - 8.6 Testrealisierung und Testdurchführung [Seite 240]
13.6.1 - 8.6.1 Microsoft Test Manager [Seite 243]
14 - 9 Ausbildung und ihre Bedeutung [Seite 246]
14.1 - 9.1 ISTQB Certified Tester [Seite 247]
14.2 - 9.2 Certified Agile Tester / CAT [Seite 252]
14.2.1 - 9.2.1 Motivation [Seite 253]
14.2.2 - 9.2.2 Training-Insights [Seite 254]
14.3 - 9.3 ISTQB Certified Tester Foundation Level Extension Agile Tester [Seite 256]
14.4 - 9.4 Individuelle Trainings (Customized Trainings) [Seite 257]
14.4.1 - 9.4.1 Empfohlenes Vorgehen bei Einführung der Agilität [Seite 257]
14.4.1.1 - 9.4.1.1 Bestandsaufnahme der Ist-Situation [Seite 257]
14.4.1.2 - 9.4.1.2 Abhängigkeitsanalyse [Seite 258]
14.4.1.3 - 9.4.1.3 Definieren des "neuen" Ziels [Seite 258]
14.4.2 - 9.4.2 Organisatorisches [Seite 258]
14.4.3 - 9.4.3 Pilotphase [Seite 258]
14.4.4 - 9.4.4 Ausrollen in Unternehmen [Seite 259]
15 - 10 Retrospektive [Seite 260]
16 - Literaturverzeichnis [Seite 263]
17 - Index [Seite 268]
Geleitwort

Im Winter 2001 wurde auf einer entlegenen Skihütte im Staate Utah von einer kleinen, verschworenen Clique bekannter Software-Entwickler zu einer Revolution in der Software-Welt aufgerufen. Sie erschufen das Agile Manifest. Mit diesem Manifest legte die Gruppe fest, was sie ohnehin schon mit Extreme Programmierung praktizierten. Aber mit der schriftlichen Formulierung gelang ihnen ein publizistischer Coup, mit dem sie weltweit Aufmerksamkeit für ihr Anliegen gewannen. Die Entwicklungsexperten, die sich dort versammelten, hatten es satt, sich von starren Prozessregeln, unsinnigen bürokratischen Richtlinien und weltfremden Vorgehensweisen der damaligen Software-Engineering-Disziplin gängeln zu lassen. Sie erkannten, dass das monotone Arbeiten nach Vorschrift in der neuen schnelllebigen Zeit überholt war. Sie wollten sich von den Fesseln der Projektbürokratie befreien, um zusammen mit den Anwendern Software nach Bedarf zu entwickeln. An die Stelle der bisher schwerfälligen, phasenorientierten, dokumentengesteuerten Software-Entwicklung sollte eine flexible, menschengesteuerte Entwicklung mit kleinen, überschaubaren Schritten treten. Die agile Software-Entwicklung sollte die Vorgehensweise des neuen Jahrhunderts sein.

Im Vordergrund der agilen Entwicklung steht nicht das Projekt, sondern das Produkt. Da Software-Entwicklung immer mehr zu einer Expedition ins Ungewisse wurde, sollte das Produkt Stück für Stück in kleinen Inkrementen entstehen. Statt lange Absichtserklärungen bzw. Anforderungsdokumente zu schreiben, über Dinge, über die man zu dem Zeitpunkt gar nicht Bescheid wissen konnte, sollte man lieber gleich etwas programmieren, um eine schnelle Rückkopplung von dem künftigen Benutzer zu bekommen. Es soll nicht mehr Monate oder gar Jahre dauern, bis sich herausstellt, dass sich das Projekt auf einem Irrweg befindet oder das Projektteam überfordert ist. Dies sollte sich schon nach wenigen Wochen erweisen.

Das Grundprinzip der agilen Entwicklung ist also die inkrementelle Lieferung. Ein Software-System soll stückweise fertiggestellt werden. Damit hat der Benutzervertreter im Team die Möglichkeit mitzuwirken. Nach jeder neuen Auslieferung kann er das ausgelieferte Zwischenprodukt mit seinen Vorstellungen vergleichen. Der Test ist dadurch in das Verfahren eingebaut. Die Software wird von Anfang an dauernd getestet. Ob da ein Tester mit im Spiel ist, wurde zunächst offengelassen. Die Verfasser des agilen Manifests waren gegen eine strenge Arbeitsteilung. Die Aufteilung in Analytiker, Designer, Entwickler, Tester und Manager war ihnen zu künstlich und verursachte zu viele Reibungsverluste. Natürlich soll das Projektteam diese Fähigkeiten besitzen, aber die Rollen innerhalb des Teams sollten austauschbar sein. Das Entwicklungsteam soll als Ganzes für alles verantwortlich sein. Erst durch die Beiträge von Crispin und Gregory hat sich die Rolle des Testers im Team herausgestellt. Die beiden haben sich dafür eingesetzt, dass sich jemand im Team um die Belange der Qualität kümmert.

Software-Entwicklung verlangt sowohl Kreativität als auch Disziplin. Gegen Ende des letzten Jahrhunderts haben die Befürworter von Ordnung und Disziplin die Oberhand gehabt und mit ihren strengen Prozessen und Qualitätssicherungsmaßnahmen die Kreativität der Entwickler vereitelt. Wenn übertrieben wird, kehrt sich alles ins Gegenteil um. Mit dem Qualitätsmanagement wurde zu viel des Guten getan. Die Gegenreaktion war die agile Bewegung, die darauf ausgerichtet war, mehr Spontaneität und Kreativität in die Software-Entwicklung zurückzubringen. Dies ist durchaus zu begrüßen, aber auch hiermit darf nicht übertrieben werden. Man braucht einen Gegenpol zu der sprudelnden Kreativität der Benutzer und Entwickler. Dieser Gegenpol ist der Tester im Team.

In jedes Entwicklungsteam gehört mindestens ein Tester, um die Belange der Qualität zu vertreten. Der Tester oder die Testerin sorgt dafür, dass das entstehende Produkt sauber bleibt und die vereinbarten Qualitätskriterien erfüllt. In dem Drang, schneller voranzukommen, geraten die nichtfunktionalen Qualitätsanforderungen gegenüber den funktionalen Anforderungen allzu leicht ins Hintertreffen. Es ist der Job des Testers, dafür zu sorgen, dass ein Gleichgewicht zwischen Produktivität und Qualität bewahrt wird. Der Tester ist sozusagen der gute Geist, der das Team davon abhält, Fortschritt auf Kosten der Qualität zu erringen. In jedem Release soll nicht nur mehr Funktionalität, sondern auch mehr Qualität angestrebt werden. Der Code soll regelmäßig bereinigt bzw. refaktoriert, nachdokumentiert und von Mängeln befreit werden. Dass dies tatsächlich geschieht, ist die Aufgabe des Testers.

Natürlich hat die agile Projektorganisation auch Folgen für den Test und die Qualitätssicherung. Die Verantwortlichen für die Qualitätssicherung sitzen nicht mehr in einer entfernten Dienststelle, von wo aus sie die Projekte überwachen, die Projektergebnisse zwischen den Phasen kontrollieren und in der letzten Phase das Produkt durchtesten. Sie sind in den Entwicklungsteams fest integriert, wo sie ständig prüfen und testen. Es obliegt ihnen, auf Mängel in der Architektur sowie im Code hinzuweisen und Fehler im Verhalten des Systems aufzudecken. Ihre Rolle ist jedoch nicht mehr die des lästigen Kontrolleurs, sondern vielmehr die des Freund und Helfers. Sie weisen auf die Probleme hin und helfen den Entwicklern, die Qualität ihrer Software auf den erforderlichen Stand zu bringen. Im Gegensatz zu dem, was manche behaupten - nämlich, dass Tester in agilen Projekten nicht mehr nötig sind -, ist ihre Rolle wichtiger denn je. Ohne ihren Beitrag wachsen die technischen Schulden und diese bringen das Projekt früher oder später zum Stillstand.

Das vorliegende Buch beschreibt den agilen Test in zehn Kapiteln. Das erste Kapitel schildert den kulturellen Wandel, den die agile Entwicklung mit sich gebracht hat. Mit dem agilen Manifest wurden die Weichen für eine Neuordnung der IT-Projektlandschaft gesetzt. Es soll nicht mehr starr nach Phasenkonzept, sondern flexibel in kleinen Iterationen entwickelt werden. Nach jeder Iteration soll ein lauffähiges Teilprodukt vorzuweisen sein. Damit werden Lösungswege erforscht und Probleme früh erkannt. Die Rolle der Qualitätssicherung wandelt sich. Statt als externe Instanz auf die Projekte von außen zu wirken, sind die Tester im Projekt eingebettet, um ihre Tests sofort vor Ort als Begleiter der Entwicklung durchzuführen. Natürlich müssen die Anwenderbetriebe ihre Managementstrukturen entsprechend anpassen: Statt abseits auf ein Endergebnis zu warten, sind die Anwender aufgefordert, im Projekt aktiv mitzumachen und die Entwicklung über ihre Anforderungen, sprich "Stories", zu steuern. Auf der Entwicklungsseite arbeiten sie mit den Entwicklern zusammen, um die gewünschte Funktionalität zu analysieren und zu spezifizieren. Auf der Testseite arbeiten sie mit den Testern zusammen, um zu sichern, dass das Produkt ihren Erwartungen entspricht.

Letztendlich müssen sich alle umstellen - Entwickler, Tester und Anwender -, um das gemeinsame Ziel zu erreichen. Manch traditionelle Rolle fällt dabei weg wie die des Projektleiters und des Testmanagers. Dafür gibt es neue Rollen wie die des Scrum Masters und des Teamtesters. Das Projektmanagement im klassischen Sinne findet nicht mehr statt. Jedes Team managt sich selbst. Die IT-Welt ändert sich und mit ihr die Art und Weise, wie Menschen Software entwickeln. Es gilt also, diesem neuen Zustand gerecht zu werden. Der Weg dazu wird hier im ersten Kapitel geschildert.

Im zweiten Kapitel über agile Vorgehensmodelle gehen die Autoren auf die Rolle der Qualitätssicherung in einem agilen Entwicklungsprojekt ein. Dabei scheuen sie sich nicht, die verschiedenen Zielkonflikte, z.?B. zwischen Qualität und Termintreue, zwischen Qualität und Budget und zwischen Qualität und Funktionalität objektiv zu betrachten. Die Versöhnung dieser Zielkonflikte ist eine Herausforderung des agilen Tests.

Im Gegensatz zur landläufigen Meinung, dass in den agilen Projekten weniger getestet werden muss, wird hier gefordert, noch mehr zu testen. Test-Driven Development (TDD) soll nicht nur für den Unit Test, sondern auch für den Integrations- und Systemtest gelten, nach der Devise: erst die Testfälle, dann der Code. Hier heißt es: erst die Testspezifikation, dann die Implementierung. Dabei spielt die Testautomation eine entscheidende Rolle. Erst wenn der Test automatisiert ist, kann in der erforderlichen Geschwindigkeit die erforderliche Qualität erreicht werden. Das ganze Team soll sich an dem Automatisierungsprozess beteiligen, denn der Tester allein kann es nicht schaffen. Er braucht die Unterstützung der Entwickler, denn er hat auch andere Aufgaben zu erledigen. Neben dem Test wird auch die Durchführung von Audits zu bestimmten Zeitpunkten in der Entstehung des Software-Produkts gefordert. Die Audits zielen darauf hin, Schwachstellen und Missstände in der Software zu enthüllen. Der Zeitpunkt dafür ergibt sich nach jedem Sprint in einem Scrum-Projekt. Aufgrund der Ergebnisse der Audits können die Prioritäten für den nächsten Sprint gesetzt werden. Diese kurzen Audits bzw. Momentaufnahmen der Produktqualität können durch QS-Experten von außen in Zusammenarbeit mit dem Team durchgeführt werden. Der Zweck ist nicht zu sehr, das Projekt durch Kritik aufzuhalten, sondern dem Team zu helfen, Risiken rechtzeitig zu erkennen.

Zusätzlich zum Scrum-Prozess behandelt das zweite Kapitel auch Kanban und den schlanken Software-Entwicklungsprozess (Lean Software). Der Leser bekommt etliche Hinweise, wie Qualitätssicherung in diesen Verfahren...

Dateiformat: EPUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat EPUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.

Inhalt (PDF)

Download (sofort verfügbar)

33,99 €
inkl. 19% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters
E-Book bestellen

Unsere Web-Seiten verwenden Cookies. Mit der Nutzung dieser Web-Seiten erklären Sie sich damit einverstanden. Mehr Informationen finden Sie in unserem Datenschutzhinweis. Ok