Agile Testing PDF
Preview Agile Testing
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 schutzGesetzgebung 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.dnb.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.hanserfachbuch.de Lektorat: Brigitte BauerSchiewek Herstellung: Irene Weilhart Copy editing: Jürgen Dubau, Freiburg/Elbe Umschlagdesign: Marc MüllerBremer, www.rebranding.de, München Umschlagrealisation: Stephan Rönigk Gesamtherstellung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, PatentNr. 0748702 Printed in Germany PrintISBN: 9783446431942 EBookISBN: 9783446432642 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 SoftwareTest . . . . . . . . . . . . . . . . . . 7 1.4 Agil setzt Kulturwandel bei den A nwendern voraus . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Konsequenzen der agilen Entwicklung für die SoftwareQualitä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 SoftwareTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 SoftwareTest aus agiler Perspektive . . . . . . . . . . . . . . . . . . . . . 56 3.1.4 Skalierbare Organisation agiler Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.2 Praxisbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.2.1 Abnahmetest als eigenes ScrumProjekt/Team . . . . . . . . . . . . . . . . . . . . . . . . 66 3.2.2 Test Competence Center für agile Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.2.3 Team im HealthcareBereich nutzt VModell . . . . . . . . . . . . . . . . . . . . . . . . . . 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 – InitialisierungsSprint . . . . . . . . . . . . . . . . 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 Sessionbasiertes 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 SoftwareEntwicklung . . . . . . . . . . . . . . . . . . 128 6.2 Der Nutzen der Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.3 Dokumentationsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.1 Anforderungsdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.2 CodeDokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 xUnitFrameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 PerformanceTest . . . . . . . . . . . . . . . . . . . . . . . . 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 SollIstVergleich 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 TOSCATestsuite . . . . . . . . . . . . . . . . . . . . . . . . 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 TrainingInsights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 SoftwareEnt wickler zu einer Revolution in der SoftwareWelt 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 SoftwareEntwicklung 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 wareSystem 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. SoftwareEntwicklung 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
The list of books you might like
