AGILE TESTING DER AGILE WEG ZUR QUALITÄT

Transkript

1 manfred BAUMGARTNER martin KLONK helmut PICHLER richard SEIDL siegfried TANCZOS AGILE TESTING DER AGILE WEG ZUR QUALITÄT Mit begleitender Homepage:

2 Inhalt Geleitwort... Vorwort... IX XVII Die Autoren... Danksagungen.... XXIII 1 Agil Ein kultureller Wandel Der Weg zur agilen Entwicklung Gründe für eine agile Entwicklung Die Bedeutung des Agilen Manifests für den Software-Test Agil setzt Kulturwandel bei den Anwendern voraus Konsequenzen der agilen Entwicklung für die Software-Qualitätssicherung Räumliche Konsequenzen Zeitliche Konsequenzen Agile Vorgehensmodelle und ihre Sicht auf Qualitätssicherung Herausforderungen in der Qualitätssicherung Qualität und Termin Qualität und Budget Der Stellenwert des Software-Tests Fehler aus Vorprojekten (Technical Debt) Testautomatisierung Hierarchische Denkweise Der Stellenwert des Teams Audits zur Qualitätssicherung in agilen Projekten Scrum Kanban Continuous Integration Lean Software Development XXI

3 VI Inhalt 3 Die Organisation des Software-Tests in agilen Projekten Die Platzierung von Tests in agilen Projekten Der fundamentale Testprozess des ISTQB Welcher Test wofür Die vier Testquadranten agilen Testens Tipps für den Software-Test aus agiler Perspektive Skalierbare Organisation agiler Teams Praxisbeispiele Abnahmetest als eigenes Scrum-Projekt/-Team Test Competence Center für agile Projekte Team im Healthcare-Bereich nutzt V-Modell Die Rolle des Testers in agilen Projekten Generalist vs. Spezialist Der Weg vom zentralen Testcenter in das agile Team Varianten der Testereinbindung in traditionellen Teams Varianten der Testereinbindung in agile Teams Herausforderungen der Tester im Team Die Tester im agilen Team Rechtzeitige Problemaufdeckung Die Entstehung technischer Schulden Teams und Tester im Kampf gegen Technical Debt Was ist Technical Debt? Der Umgang mit technischen Schulden Zu alt für agil? Die mentale Herausforderung Ausgangslage Was führt zur Aussage Agil ist etwas für junge Leute? Hilfreiche Tipps vom Markt Agiles Testmanagement, -methoden und -techniken Testmanagement Testplanung im traditionellen Umfeld Testplanung im agilen Umfeld Testkonzept Testaktivitäten in Iteration Zero Initialisierungs-Sprint Externe Unterstützung der Testplanung Testschätzung Testorganisation Testerstellung, Durchführung und Release Testmethoden im agilen Umfeld Risikobasiertes und valuebasiertes Testen Explorativer Test Session-basiertes Testen Abnahmetestgetriebene Entwicklung Testautomatisierung

4 Inhalt VII 5.3 Wesentliche Einflussfaktoren auf den Test Continuous Integration (CI) Automatisiertes Konfigurationsmanagement Agile Testdokumentation Die Rolle der Dokumentation in der Software-Entwicklung Der Nutzen der Dokumentation Dokumentationsarten Anforderungsdokumentation Code-Dokumentation Testdokumentation Benutzerdokumentation Der Tester als Dokumentierer Stellenwert der Dokumentation im agilen Test Agile Testautomatisierung Die Crux mit den Werkzeugen in agilen Projekten Testautomatisierung Wie geht man es an? Testautomatisierung mit zunehmender Integration der Software Unit Test bzw. Komponententest Komponentenintegrationstest Systemtest Systemintegrationstest xunit-frameworks Einsatz von Platzhaltern Integrationsserver Testautomatisierung im fachlich orientierten Test Ein Framework wozu? Agile versus klassische Automatisierung von Benutzereingaben Ein typisches Beispiel: FitNesse und Selenium Testautomatisierung im Last- und Performance-Test Die sieben schlechtesten Ideen für die Testautomatisierung Den Erfolg nach wenigen Sprints erwarten Testwerkzeugen blind vertrauen Schreiben der Testskripts als Nebenbeschäftigung ansehen Testdaten irgendwo in Testfällen vergraben Testautomatisierung nur mit Benutzeroberflächen in Verbindung bringen Soll-Ist-Vergleich unterschätzen (Un-)Testbarkeit der Applikation einfach hinnehmen Werkzeugeinsatz in agilen Projekten Projektmanagement Rally

5 VIII Inhalt 8.2 Anforderungsmanagement Polarion QA/ALM Fehlermanagement The Bug Genie Atlassian JIRA Testplanung und -steuerung Atlassian JIRA Testanalyse und Testentwurf Risikobasiertes Testen in der TOSCA-Testsuite Testrealisierung und Testdurchführung Microsoft TFS Test Manager Ausbildung und ihre Bedeutung ISTQB Certified Tester Certified Agile Tester/CAT Motivation Training-Insights Individuelle Trainings (Customized Trainings) Empfohlenes Vorgehen bei Einführung der Agilität Organisatorisches Pilotphase Ausrollen in Unternehmen Retrospektive Literaturverzeichnis Index

6 1 Agil Ein kultureller Wandel Um den kulturellen Wandel hin zur agilen Software-Entwicklung und besser zu verstehen und Agile Testing nicht nur als neues Schlagwort zu begreifen, macht es Sinn, etwas in die Vergangenheit zu blicken. Vieles von dem, was wir heute als neuartig wahrnehmen hat seine Begründung in den methodischen und technischen Weiterentwicklungen der Software-Technologie der letzten 30 Jahre. Erfahrung ist ein wesentliches Element für Innovation und Entwicklung. So lag zum Beispiel der Altersdurchschnitt der Unterzeichner des Agilen Manifests im Jahre 2001 bei ca. 47 Jahren. Und damals ging es auch nicht darum, einfach alles nur anders zu machen, sondern besser. Dies wird heute gerne übersehen, wenn Agil dafür herhalten muss, einfach unangenehmes loszuwerden oder eigene Schwächen nachträglich als immer schon agile Methode schönzureden. Der ehrliche Ansatz, die Entwicklung von Software in einer partnerschaftlichen, nutzenorientierten und auch effizienten, sprich wirtschaftlichen Art und Weise zu betreiben, steht im Kern der agilen Idee. 1.1 Der Weg zur agilen Entwicklung Der Übergang zur agilen Entwicklung in der IT-Projektpraxis ist schon länger im Gange, und zwar seit der Verbreitung der objektorientierten Programmierung in den späten 1980er bzw. frühen 1990er Jahren. Der objektorientierte Ansatz veränderte die Art und Weise, wie Software entwickelt wird. Die vordergründigen Ziele der Objekttechnologie waren Steigerung der Produktivität durch Wiederverwendung Reduktion der Codemenge durch Vererbung und Assoziation Erleichterung der Codeänderung durch kleinere, austauschbare Codebausteine Einschränkung der Fehlerauswirkung durch die Kapselung der Codebausteine [Meye97]. Diese Ziele waren durchaus berechtigt, denn die alten prozeduralen Systeme wurden immer größer und platzten aus den Nähten. Die Codemenge drohte ins Unermessliche zu steigen. Also musste ein Weg gefunden werden, die Codemenge bei gleicher Funktionalität zu reduzieren. Die Antwort war die Objektorientierung. Es entstanden neue Programmiersprachen wie C++, C# und Java. Die Anwender begannen, auf die neue Programmiertechnologie umzustellen [Grah95].

7 2 1 Agil Ein kultureller Wandel Allerdings hatte diese technologische Verbesserung auch einen Preis, nämlich die Steigerung der Komplexität. Durch die Zerlegung des Codes in kleine, mehrfach verwendbare Bausteine stieg die Anzahl der Beziehungen, sprich Abhängigkeiten zwischen den Codebausteinen. Bei der prozeduralen Software lag die Komplexität in den einzelnen Bausteinen, deren Ablauflogik immer tiefer verschachtelt wurde. Bei objektorientierter Software ist die Komplexität in die Architektur ausgelagert. Somit wurde es schwieriger, einen Überblick über das Ganze zu behalten und eine geeignete Architektur im Voraus zu planen. Der Code musste mehrfach überarbeitet werden, bis eine akzeptable Lösung zustande kam. Bis dahin befand sich der Code oft in einem chaotischen Zustand. Es gab zwei Antworten auf diese Herausforderung. Die eine war Modellierung. Im Laufe der 1990er Jahre sind unterschiedliche Modellierungssprachen vorgeschlagen worden: OMT, SOMA, OOD usw. Am Ende setzte sich eine durch: UML. Durch die Darstellung der Software- Architektur in einem Modell sollte es möglich sein, die optimale Struktur zu finden sowie einen Überblick zu gewinnen und zu behalten. Die Entwickler würden so die Erwartung das passende Modell erstellen und danach in den konkreten Code umsetzen [Rumb91]. Software Engineering stellte sich von der prozeduralen zur objektorientierten Modellierung mit Anwendungsfällen um. Damit wurde die Modellierung viel feiner und mit neuen Werkzeugen wie Rational Rose unterstützt [Jaco92]. Das Modellieren hat sich jedoch auch mit der besten Werkzeugunterstützung als sehr langwierig erwiesen. Der Entwickler brauchte lange, bis das Modell in allen Einzelheiten ausgearbeitet war. Inzwischen hatten sich die Anforderungen geändert, und die Prämissen, auf den das Modell aufgebaut war, galten nicht mehr. Der Modellierer musste wieder von vorne anfangen, und der Kunde wurde immer ungeduldiger. Eine andere Antwort auf die Herausforderung der steigenden Komplexität war Extreme Programming [Beck00], Bild 1.1. Da man das geeignete Modell für die Software nicht voraussehen konnte, haben die Entwickler begonnen, die Anforderungen in enger Kommunikation mit dem Anwender und in kurzen Iterationen direkt in den Code zu übersetzen. Gesamtes Team Collective Ownership Test-Driven Development Kommunikation Anwendertests Pair Programming Refactoring Planning Game Continuous Integration Einfaches Design Codier- Standards Nachhaltiges Tempo Metapher Kurze Iterationen Bild 1.1 XP-Praktiken

8 1.1 Der Weg zur agilen Entwicklung 3 Dieser Ansatz birgt die Gefahr, dass man sich in eine Sackgasse verläuft, hat aber den Vorteil, dass der Kunde bald etwas zu sehen bekommt. Wenn die Codebausteine flexibel ge staltet sind, kann man sie auch dann wiederverwenden, wenn man sich in einer Sackgasse befindet und einen anderen Weg einschlagen muss. Ein weiterer Vorteil von Extreme Programming war, dass man den Anwender auf die Reise mitnehmen konnte. Er konnte die Ereignisse der Programmierung die realen Benutzeroberflächen, Listen, Nachrichten und Datenbankinhalte verfolgen, was er bei der abstrakten Modellierung nicht konnte. Also setzte sich in der Praxis Extreme Programming durch, und die Modellierung blieb mehr oder weniger in der akademischen Ecke. Als nützliche Folgeerscheinung des Extreme Programming stellte sich das Test-Driven Development heraus [Beck03]. Wenn man sich in ein unbekanntes Gelände vortastet, muss man sich absichern. Die Absicherung in der Code-Entwicklung ist der Testrahmen. Der Entwickler baut zuerst einen Testrahmen auf und füllt ihn dann mit kleinen Codebausteinen aus [Janz05]. Jeder Baustein wird sofort getestet, ob er auch passt. Der Entwickler sucht seinen Weg durch das Codegelände und sichert immer durch Test seinen letzten Stand. Auf diese Weise erreicht er letztlich einen befriedigenden, getesteten Zwischenzustand, den er dem Anwender vorführen kann. In der Software-Entwicklung gibt es nur Zwischenzustände, da Software per Definition nie endgültig fertig ist. Test-Driven Development hat sich auch außerhalb von Extreme Programming als eine sehr solide Vorgehensweise bewährt. Dies wurde auch von mehreren wissenschaftlichen Untersuchungen bestätigt, und Unit Tests sowie Continuous Integration wurden zum Standard in der Software-Entwicklung. Es versteht sich, dass Extreme Programming und Test-Driven Development in Widerspruch zu den herrschenden Managementmethoden standen. Das Management von Software-Projekten setzte eine planbare, prädisponierte Entwicklung voraus, bei der es möglich ist festzulegen, was geliefert wird, wann es geliefert wird und was es kosten wird. Systematisches Software Engineering sollte dafür sorgen (siehe Bild 1.2). Projektleiter Analytiker Qualitätsmanager Der Prozess über alles Entwickler fühlen sich durch bürokratische Prozesse unterdrückt Bild 1.2 Software Engineering schafft Ordnung in einer chaotischen Software-Welt

9 4 1 Agil Ein kultureller Wandel Die 1990er Jahre waren auch das Jahrzehnt der Prozessmodelle, des Qualitätsmanagements und des unabhängigen Testens, kurzum das Jahrzehnt des Software Engineerings. Mit Software Engineering sollte durch wohldefinierte Prozesse mit einer strengen Arbeitsteilung Ordnung in der Software-Entwicklung und -Wartung hergestellt werden. Es wurde mit der freien, uneingeschränkten Entwicklung Schluss gemacht. Viele Maßnahmen wurden seitens des Managements ergriffen, um die Software-Entwicklung endlich unter Kontrolle zu bringen. Das V-Modell ist stellvertretend für jene Versuche, die Software-Entwicklung zu strukturieren [Höhn08]. Leider standen die meisten dieser Maßnahmen in krassen Widerspruch zu der neuen extremen Entwicklungstechnik. 1.2 Gründe für eine agile Entwicklung Einer der wichtigsten Gründe für die agile Entwicklung ist die Nähe zum Anwender. In der klassischen, nicht-agilen Entwicklung ist die Kluft zwischen Entwicklern und Anwendern immer größer geworden. In der 70er Jahren des letzten Jahrhunderts war diese Kluft noch nicht so groß. Als Harry Sneed, der dankenswerterweise auch ein Geleitwort zu diesem Buch verfasst hat, seine Karriere als Programmierer begann, pendelte der Entwickler jeden Tag zwischen seinen Auftraggebern in der Fachabteilung, seinem Schreibtisch und dem Rechenzentrum. Mit dem Anwender besprach er fast jeden Tag die Aufgabe, an seinem Schreibtisch schrieb er das Programm, und im Rechenzentrum probierte er es aus, meistens abends. Die Nähe zum Kunden war das Allerwichtigste. Im Laufe der 1980er und 1990er Jahre hat sich die Arbeitsweise geändert. In der traditionellen Testwelt, die von Gelperin und Hetzel Mitte der 1980er Jahre ins Leben gerufen wurde, herrscht ein grundsätzliches Misstrauen gegenüber dem Entwickler. Es wurde an genommen, dass die Entwickler auf sich alleine gestellt fehlerhafte und qualitativ minderwertige Software produzieren werden [Hetz88]. Hinzu kommt, dass sie die eigenen Fehler nicht erkennen, und wenn doch, werden sie zu unvermeidlichen Eigenschaften der Software deklariert: It s a feature, not a bug. Über die Qualität ihrer Architektur und ihres Codes lassen sie nicht mit sich reden. Es ist aus ihrer Sicht alles immer bestens. Es besteht kein Bedarf, sie zu verbessern. Mit diesem Bild des Entwicklers im Hinterkopf erfolgte der Ruf nach einer separaten Testorganisation. Es sollte in größeren Projekten eine separate Testgruppe geben, die mehrere Projekte betreut. Jedenfalls musste die Testgruppe unabhängig von den Entwicklern sein. Dies war die Grundvoraussetzung dafür, dass die Tester effektiv arbeiten. Es sollte ein System zustande kommen, in dem die Tester die Arbeit der Entwickler kontrollieren. Die Entwickler produzieren die Fehler, und die Tester finden sie. Ein Fehlermeldungs- und -verfolgungssystem sollte die Kommunikation zwischen den beiden Gruppen unterstützen. Diese Arbeitsteilung zwischen Entwicklern und Testern wurde weltweit propagiert und praktiziert. Daraus gingen neue Begriffe wie quality engineering und Qualitätsmanagement hervor. Es ging so weit, dass jeder größere Betrieb einen Qualitätsmanager haben sollte. Das forderten die ISO-9000 Standards. Und wo es Management gibt, gibt es auch Bürokratie. Es entstand eine Software-Qualitätsbürokratie, basierend auf Normen und Vorschriften, die die Entwickler anleiten sollten, korrekt zu arbeiten [ISO 05a].

10 1.2 Gründe für eine agile Entwicklung 5 Typisch dafür war der Entwicklungsprozess bei der Bertelsmann AG das Software Engineering Modell Bertelsmann. Danach sollte die Fachabteilung zunächst eine vollständige Fachinhaltsbeschreibung erstellen. Diese wurde von der Qualitätssicherung der Ent wicklungsabteilung angenommen und eine Aufwandsschätzung gemacht [Bend83] (siehe Bild 1.3). Fachabteilung Zentrale DV-Abteilung Systemanalyse durch die Fachabteilung Systementwurf durch die Architekten Systemabnahmetest Entwurfsdokumente Fachinhaltsbeschreibung Software Qualitätssicherung Programmierung durch die Entwickler QS prüft Konzept, Entwurf & Code COBOL Code DV System Modul & Integrationstest Bild 1.3 Das Software Engineering Modell Bertelsmann Auf der Basis dieser Aufwandsschätzung wurde eine Vereinbarung mit der Fachabteilung getroffen: mit einem festen Preis, mit einem festen Termin und einem festen Ergebnis. Danach wurden die Anforderungen eingefroren und zunächst in einem Systementwurf umgesetzt. Dieser wurde dem Kunden präsentiert, der diesen selten verstanden hat oder besser gesagt verstehen konnte. Meistens nickten die Anwender nur mit dem Kopf und meinten, es würde schon gut sein. Auf den Systementwurf folgten die Implementierung und der Test, wobei der Test meistens länger dauerte als geplant. Viele Monate, manchmal sogar Jahre später wurde dem Anwender das fertige System präsentiert. Seine Reaktion war oft, dass er sich das so nicht vorgestellt hätte. Bei Bertelsmann führte dieser wohlgemeinte, aber schwerfällige Prozess letztendlich zur Umorganisation der IT und zur Verteilung der Entwickler auf die Fachabteilungen. Andere deutsche Anwenderbetriebe hatten das Bertelsmann-Modell ebenfalls übernommen, aber das Ergebnis war meistens dasselbe wie bei Bertelsmann: enttäuschte Anwender. Der Schluss daraus ist, dass die Trennung der Entwickler von den Anwendern nie gut funktioniert hat. Ein klassisches Beispiel für einen bürokratischen Entwicklungsprozess ist das V-Modell bzw. das V-Modell-XT [Raus06]. Dieses Modell wurde im ersten Range für die Software-