manfred BAUMGARTNER martin KLONK helmut PICHLER richard SEIDL siegfried TANCZOS AGILE TESTING DER AGILE WEG ZUR QUALITÄT Mit begleitender Homepage: http://www.agile-testing.eu Baumgartner/Klonk/Pichler/Seidl/Tanczos Agile Testing Bleiben Sie auf dem Laufenden! Der Hanser Computerbuch-Newsletter informiert Sie regelmäßig über neue Bücher und Termine aus den verschiedenen Bereichen der IT. Profitieren Sie auch von Gewinnspielen und exklusiven Leseproben. Gleich anmelden unter www.hanser-fachbuch.de/newsletter Manfred Baumgartner Martin Klonk Helmut Pichler Richard Seidl Siegfried Tanczos Agile Testing Der agile Weg zur Qualität Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bes­ tem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz aus­ zuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Die Autoren und der Verlag über­ nehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen die Autoren und der Verlag keine Gewähr dafür, dass beschriebene Ver fahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handels namen, Waren be zeich nungen usw. in diesem Buch berechtigt deshalb auch ohne beson­ dere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen­ und Marken schutz­Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbiblio­ grafie; detaillierte bibliografische Daten sind im Internet über http://dnb.d­nb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Sys­ teme verarbeitet, vervielfältigt oder verbreitet werden. © 2013 Carl Hanser Verlag München, www.hanser­fachbuch.de Lektorat: Brigitte Bauer­Schiewek Herstellung: Irene Weilhart Copy editing: Jürgen Dubau, Freiburg/Elbe Umschlagdesign: Marc Müller­Bremer, www.rebranding.de, München Umschlagrealisation: Stephan Rönigk Gesamtherstellung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent­Nr. 0748702 Printed in Germany Print­ISBN: 978­3­446­43194­2 E­Book­ISBN: 978­3­446­43264­2 Inhalt Geleitwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII Die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII 1 Agil – Ein kultureller Wandel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Der Weg zur agilen Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Gründe für eine agile Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Die Bedeutung des Agilen Manifests für den Software­Test . . . . . . . . . . . . . . . . . . 7 1.4 Agil setzt Kulturwandel bei den A nwendern voraus . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Konsequenzen der agilen Entwicklung für die Software­Qualitätssicherung . . . . 11 1.5.1 Räumliche Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.2 Zeitliche Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2 Agile Vorgehensmodelle und ihre Sicht auf Qualitätssicherung . . . 15 2.1 Herausforderungen in der Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.1 Qualität und Termin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2 Qualität und Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.3 Der Stellenwert des Software­Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.4 Fehler aus Vorprojekten (Technical Debt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.5 Testautomatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.6 Hierarchische Denkweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Der Stellenwert des Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Audits zur Qualitätssicherung in agilen Projekten . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5 Lean Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 VI   Inhalt 3 Die Organisation des Software-Tests in agilen Projekten . . . . . . . . . . 37 3.1 Die Platzierung von Tests in agilen Projekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.1 Der fundamentale Testprozess des ISTQB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.2 Welcher Test wofür – Die vier Testquadranten agilen Testens . . . . . . . . . . . . 46 3.1.3 Tipps für den Software­Test aus agiler Perspektive . . . . . . . . . . . . . . . . . . . . . 56 3.1.4 Skalierbare Organisation agiler Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.2 Praxisbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.2.1 Abnahmetest als eigenes Scrum­Projekt/­Team . . . . . . . . . . . . . . . . . . . . . . . . 66 3.2.2 Test Competence Center für agile Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.2.3 Team im Healthcare­Bereich nutzt V­Modell . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4 Die Rolle des Testers in agilen Projekten . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.1 Generalist vs. Spezialist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2 Der Weg vom zentralen Testcenter in das agile Team . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.1 Varianten der Testereinbindung in traditionellen Teams . . . . . . . . . . . . . . . . 74 4.2.2 Varianten der Testereinbindung in agile Teams . . . . . . . . . . . . . . . . . . . . . . . . 75 4.3 Herausforderungen der Tester im Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.3.1 Die Tester im agilen Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.3.2 Rechtzeitige Problemaufdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.3.3 Die Entstehung technischer Schulden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.4 Teams und Tester im Kampf gegen „ Technical Debt“ . . . . . . . . . . . . . . . . . . . . . . . . 90 4.4.1 Was ist „Technical Debt“? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.4.2 Der Umgang mit technischen Schulden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.5 Zu alt für agil? Die mentale Herausforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.5.1 Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.5.2 Was führt zur Aussage „Agil ist etwas für junge Leute“? . . . . . . . . . . . . . . . . . 94 4.6 Hilfreiche Tipps vom Markt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5 Agiles Testmanagement, -methoden und -techniken . . . . . . . . . . . . . . 101 5.1 Testmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.1.1 Testplanung im traditionellen Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.1.2 Testplanung im agilen Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.1.3 Testkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.1.4 Testaktivitäten in Iteration Zero – Initialisierungs­Sprint . . . . . . . . . . . . . . . . 108 5.1.5 Externe Unterstützung der Testplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.1.6 Testschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.1.7 Testorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.1.8 Testerstellung, Durchführung und Release . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.2 Testmethoden im agilen Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.2.1 Risikobasiertes und valuebasiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.2.2 Explorativer Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.2.3 Session­basiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.2.4 Abnahmetestgetriebene Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.2.5 Testautomatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Inhalt V I I 5.3 Wesentliche Einflussfaktoren auf den Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.3.1 Continuous Integration (CI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.3.2 Automatisiertes Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6 Agile Test dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.1 Die Rolle der Dokumentation in der Software­Entwicklung . . . . . . . . . . . . . . . . . . 128 6.2 Der Nutzen der Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.3 Dokumentationsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.1 Anforderungsdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.2 Code­Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 6.3.3 Testdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6.3.4 Benutzerdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.4 Der Tester als Dokumentierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.5 Stellenwert der Dokumentation im agilen Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 7 Agile Test automatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.1 Die Crux mit den Werkzeugen in agilen Projekten . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.2 Testautomatisierung – Wie geht man es an? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.3 Testautomatisierung mit zunehmender Integration der Software . . . . . . . . . . . . . 145 7.3.1 Unit Test bzw. Komponententest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 7.3.2 Komponentenintegrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 7.3.3 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 7.3.4 Systemintegrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 7.4 xUnit­Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 7.5 Einsatz von Platzhaltern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.6 Integrationsserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 7.7 Testautomatisierung im fachlich orientierten Test . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.7.1 Ein Framework – wozu? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7.7.2 Agile versus klassische Automatisierung von Benutzereingaben . . . . . . . . . . 158 7.7.3 Ein typisches Beispiel: FitNesse und Selenium . . . . . . . . . . . . . . . . . . . . . . . . 161 7.8 Testautomatisierung im Last­ und Performance­Test . . . . . . . . . . . . . . . . . . . . . . . . 166 7.9 Die sieben schlechtesten Ideen für die Testautomatisierung . . . . . . . . . . . . . . . . . 167 7.9.1 Den Erfolg nach wenigen Sprints erwarten . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 7.9.2 Testwerkzeugen blind vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 7.9.3 Schreiben der Testskripts als Nebenbeschäftigung ansehen . . . . . . . . . . . . . . 168 7.9.4 Testdaten irgendwo in Testfällen vergraben . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 7.9.5 Testautomatisierung nur mit Benutzeroberflächen in Verbindung bringen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 7.9.6 Soll­Ist­Vergleich unterschätzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 7.9.7 (Un­)Testbarkeit der Applikation einfach hinnehmen . . . . . . . . . . . . . . . . . . . 170 8 Werkzeugeinsatz in agilen Projekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 8.1 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 8.1.1 Rally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 VIII   Inhalt 8.2 Anforderungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.2.1 Polarion QA/ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 8.3 Fehlermanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 8.3.1 The Bug Genie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 8.3.2 Atlassian JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 8.4 Testplanung und ­steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 8.4.1 Atlassian JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 8.5 Testanalyse und Testentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.5.1 Risikobasiertes Testen in der TOSCA­Testsuite . . . . . . . . . . . . . . . . . . . . . . . . 196 8.6 Testrealisierung und Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.6.1 Microsoft TFS Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 9 Ausbildung und ihre Bedeutung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 9.1 ISTQB Certified Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.2 Certified Agile Tester/CAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.2.2 Training­Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.3 Individuelle Trainings (Customized Trainings) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.3.1 Empfohlenes Vorgehen bei Einführung der Agilität . . . . . . . . . . . . . . . . . . . . 214 9.3.2 Organisatorisches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.3.3 Pilotphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.3.4 Ausrollen in Unternehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 10 Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Geleitwort Im Winter 2001 wurde von einer kleinen, verschwo renen Clique bekannter Software­Ent­ wickler zu einer Revolution in der Software­Welt aufgerufen. Sie erschufen das Agile Mani­ fest. Mit diesem Manifest legte die Gruppe fest, was sie ohnehin schon mit Extreme Pro­ grammierung praktizierte. Aber mit der schriftlichen Formulierung gelang ihnen ein publizistischer Coup, mit dem sie weltweit Aufmerksamkeit für ihr Anliegen gewannen. 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ärun­ gen bzw. Anforderungsdokumente zu schreiben, über Dinge, über die man zu dem Zeit­ punkt 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 das Projekt sich 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 Soft­ ware­System soll stückweise fertiggestellt werden. Damit hat der Benutzervertreter im Team die Möglichkeit mitzuwirken. Nach jeder neuen Auslieferung kann er das ausgelie­ ferte Zwischenprodukt mit seinen Vorstellungen vergleichen. Der Test ist dadurch in das Verfahren eingebaut. Die Software wird vom Anfang an dauernd getestet. Ob da ein Tester mit im Spiel ist, wurde zunächst offengelassen. So wie bei ihrem Vorbild Karl Marx in sei­ nem kommunistischen Manifest waren die Verfasser des agilen Manifests 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 heraus­ gestellt. 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 letz­ ten 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