Agile entwicklungsnahe Testprozesse

Transkript

1 Agile entwicklungsnahe Testprozesse Agile Testing in der Praxis Agile entwicklungsnahe Testprozesse Es gibt eine Vielzahl an Möglichkeiten und Best Practices, die mit einer Mischung aus Pragmatismus und Effektivität umsetzbar sind. Effektivität in diesem Kontext bedeutet für die Tester, so viele Fehler so früh wie möglich zu finden, um die Qualität des Produkts verbessern zu können. Pragmatismus dagegen bedeutet, die Methoden des Lehrbuchs flexibel handzuhaben und an die gegebenen Rahmenbedingungen anzupassen, um den Testern einen effektiven Test zu ermöglichen. Im Laufe der Zeit haben sich einige Testprozesse herauskristallisiert, die durchgängig eine hohe Entwicklungsqualität sicherstellen können. Im Folgenden werden nun einige dieser Prozesse aus je einem Projekt im Bankenumfeld und der Telekommunikationsbranche beschrieben. Die PENTASYS AG verfügt über ein großes Spektrum praktischer Erfahrungen in agilen Projekten, sowohl in der Entwicklung als auch in der Qualitätssicherung. In diesem Artikel möchten wir Ihnen einen Einblick in unsere Erfahrungen geben. In unseren Kundenprojekten haben wir Testprozesse entwickelt, welche frühzeitig eine hohe Qualität in der agilen Softwareentwicklung sicherstellen. Tester Goes Wild (TGW) In der agilen Softwareentwicklung erfolgt die Umsetzung meist in mehreren Entwicklungszyklen. In traditionellen Testmethoden dagegen wird die Überprüfung der zu erbringenden Arbeit in der Regel erst am Ende eingeplant. In unserem Fall wäre das aber am Ende eines Zyklus, wenn die geplante Aufgabe mit all Ihren Akzeptanzkriterien erledigt ist. Mit Tester Goes Wild wird versucht, die Qualität der Entwicklung so oft wie möglich sicherzustellen. Sobald einzelne abprüfbare Bestandteile oder Methoden, entwickelt wurden, übernimmt ein an der Entwicklung beteiligter Mitarbeiter (egal ob Tester oder Entwickler) die TGW-Aufgabe und versucht gezielt Schwachstellen in den bereits entwickelten Komponenten zu finden. Findet er keine Schwachstellen, wird mit der Entwicklung fortgefahren. Gefundene Fehler werden sofort beseitigt. Der Tester trägt sein Kürzel bei der Aufgabe ein und hakt dieses ab sobald er fertig ist. Der TGW Prozess kann bis zur fertigen Umsetzung aller Akzeptanzkriterien mehrfach wiederholt werden. PENTASYS-Blickpunkte

2 Test QS Wurden alle Akzeptanzkriterien einer geplanten Aufgabe fertig umgesetzt, führt das Entwicklungsteam als letzten Schritt eine Test-Qualitätssicherung durch. Diese dient zur eigenen Kontrolle für das Team. Hierbei wird sowohl die erfolgreiche Umsetzung aller Akzeptanzkriterien überprüft und schriftlich bestätigt, als auch, dass alle zuvor vereinbarten allgemeingültigen Programmierrichtlinien (Definition of Done) eingehalten wurden. Das fertige Test-QS Dokument gilt anschließend als Abnahmekriterium für den Auftraggeber. Functional Check durch Code-Reviewer und Tester Wurde eine Anforderung fertig entwickelt, steht diese zum Code-Review bereit. Der Entwickler, welcher das Code-Review durchführt, holt sich den Tester zu sich, um gemeinsam einen Functional-Check durchzuführen. Hier wird überprüft, ob die Software den Anforderungen entspricht. Der Fokus hier steht auf dem WAS: Hat der Entwickler grundsätzlich das geliefert, was angefordert wurde. Zum Zeitpunkt des Functional Checks stehen im besten Fall die High-Level Testfälle (auch Testaspekte genannt) zur Verfügung und dienen als Basis der Überprüfungen. Gefundene Fehler werden vom Reviewer im direkt Rahmen des Reviews beseitigt. Test Session und explorative Testing Um die gesamte bisherige Entwicklung in Form eines Integrationstests abzuprüfen, gibt es den Prozess der Test Session. Hierbei betrachten alle an der Entwicklung beteiligten Mitarbeiter innerhalb eines vorgegebenen Zeitrahmens (timeboxed) die bisherige Gesamtanwendung und versuchen diese auf Herz und Nieren zu testen. In der traditionellen Test Session werden in der ersten Hälfte der Zeit einige zuvor erstellte Testfälle ausgeführt und in der zweiten Hälfte die Anwendung durch exploratives Testen intensiv betrachtet. Unterstützt und geleitet wird diese Test Session vom entwicklungsnahen Tester. Dieser teilt allen Teilnehmern die durchzuführenden Testfälle zu und gibt den Hauptfokus für das explorative Testen vor (z.b. Grenzwerttests, Umgang mit Sonderzeichen, Lasttests, ). Ein wichtiger Gesichtspunkt der Test Session ist es, allen an der Entwicklung Beteiligten einen Gesamtüberblick über das zu entwickelnde Produkt zu verschaffen. Dies kann durch den entwicklungsnahen Tester bewusst gesteuert werden, indem er durch gezielte Zuweisung von Testfällen einzelne Teilnehmer dazu bringt Anwendungsbereiche zu betrachten, welche er eventuell selbst nicht entwickelt hat. Durch ein besseres Verständnis der Gesamtanwendung erhöht sich ebenso die Qualität der Entwicklung, da die möglichen Auswirkungen einzelner Codezeilen in anderen Anwendungsbereichen frühzeitig bedacht und entsprechend optimiert werden können. Hier gibt es noch weitere Ansätze wie die Testtouren 1 zu erwähnen. Jede Tour hat einen sprechenden Namen. Es wird dabei mit unterschiedlichen Herangehensweisen die Software getestet und jede deckt dabei einen bestimmten Inhalt ab. 2 PENTASYS Blickpunkte - Agile entwicklungsnahe Testprozesse

3 Als erfolgreich durchgeführte Test-Touren können folgende erwähnt werden: Garbage Collector Tour Supermodel Tour Backalley Tour Coach Potato Tour Fedex Tour Landmark Tour Antisocial Tour Die agilen Testtouren werden in einem weiteren Blickpunkte Artikel ausführlich dargestellt. Continuous Integration Prozess Ein sehr wichtiger Erfolgsfaktor für die funktionierende Qualitätssicherung in den beiden Projekten war eine frühzeitige Automatisierung von Testfällen. Das Ziel der Testautomatisierung war jedoch nicht, alle Anforderungen durch automatisierte Tests abzudecken. Es wurden nur die Anforderungen gezielt durch automatisierte Tests abgedeckt, welche durch den Tester während des Test-Designs zuvor selektiert wurden. Diese Tests sind die bereits genannten konkreten Testfälle, die aus den High-Level-Testfällen abgeleitet werden. Sie entlasten den Tester und sorgen in zukünftigen Iterationen dafür, dass bereits implementierte Features weiterhin funktionieren. Die automatisierten Tests waren Teil des Build Prozesses. Die Build-Pipeline sah wie folgt aus: Deployment Testumgebung für Tests von neuen Features Automatisierter Test (Regression) Deployment Integration Komponententest Buildausführung Step 1: Buildausführung (inklusive statischer Codeanalyse und Kompilierung) PENTASYS Blickpunkte - Agile entwicklungsnahe Testprozesse 3

4 Step 2: Wenn Step 1 grün ist, dann Ausführung der Komponenttests (Unit-/Komponententest, siehe Test Automation Pyramid von Mike Cohn 2 ) Wenn Step 1 rot ist, dann erst die Probleme im Build beheben Step 3: Wenn Step 2 grün ist, dann Deployment in der Integrationstestumgebung Wenn Step 2 rot ist, dann gefundene Fehler (während der Unit-Tests) beheben Step 4: Wenn Step 3 grün ist, dann die Automatisierten Integrationstests (Regressionstests von bereits implementierten Features) durchführen Wenn Step 3 rot ist, Problem beim Deployment beheben Step 5: Wenn Step 4 grün ist, dann Deployment in der Testumgebung für die manuelle Testdurchführung von neuen implementierten Features, Änderungen oder Fehlernachtests im Sprint Wenn Step 4 rot ist, gefundene Fehler (während der Integrationstests) beheben, sonst finden keine manuellen Tests der neuen Features/Story der aktuellen Iteration statt. Step 6: Wenn Step 5 grün ist, dann Veröffentlichung der Ergebnisse auf einem für den Zweck entwickelten Dashboard. Code ist danach bereit für die End-to-End Testumgebungen. Mit diesem Einsatz wurden die Integrations-, Deployment- und Delivery-Prozesse so automatisiert, dass das Team viel Zeit gewinnen konnte und vor allem jederzeit in der Lage war, die Qualität der Software zu überwachen. Zusätzliches Werkzeug und als Quality-Gate im Einsatz war Sonar. Mit diesem Tool kann der entwickelte Quellcode auf vordefinierte Qualitätsmerkmale analysiert und eine Auswertung geliefert werden. Die Entwickler waren aufgefordert, nach der Implementierung einer Anforderung die Unit-Tests zu schreiben, diese zu überprüfen, auf ein erfolgreiches Maven-Build zu schauen und zu kontrollieren, dass Sonar als Quality-Gates sein OK gibt. Make it Big: Agile Tester in einem größeren Bank Projekt Der Einsatz entwicklungsnaher Testmethoden ist unabhängig von der Projektgröße möglich. Bei größeren Projekten ist für die entwicklungsnahen Tester allerdings mehr Organisationsaufwand notwendig. Im Folgenden werden einige Praxisbeispiele für agile Testmethoden aus einem Scrum of Scrums-Projekt mit fünf Entwicklungsteams beschrieben. Zu jedem Entwicklungsteam gehört ein entwicklungsnaher Tester. Die folgenden Maßnahmen können innerhalb einer Test Session durchgeführt werden: Pair Testing Um einen Wissensaustausch zwischen den einzelnen Teams zu ermöglichen, wurde die Variante des Pair Testing angewandt. Hierbei führen jeweils zwei Entwicklungsteams die Test Session gemeinsam durch. Der entwicklungsnahe Tester ordnet jeweils zwei Entwickler der unterschiedlichen Teams einander zu. Anschließend führt jeweils ein Entwickler einen Testfall über die Bereiche des anderen Entwicklungsteams durch und stellt dabei so viele Fragen an seinen Partner wie möglich. Der Partner erklärt ebenfalls proaktiv dem Testausführenden, welche Besonderheiten es in den jeweiligen Bereichen gibt und wo ggf. die Schwierigkeiten während der Entwicklung lagen. 2 PENTASYS Blickpunkte - Agile entwicklungsnahe Testprozesse

5 Prozesstest Gerade in komplexeren Anwendungen ist es für die Entwicklung schwierig, den Gesamtprozess bei Verwendung der Anwendung im Blick zu haben. Jeder arbeitet in seinem speziellen Bereich und hat dadurch selten den Anwenderblick auf das große Ganze. Hierzu kann innerhalb einer Test Session der Prozesstest durchgeführt werden. In unserem Fall hatte jedes SCRUM Entwicklungsteam seinen eigenen Project Owner. Dieser hatte das fachliche Wissen über die Gesamtanwendung und konnte während der Testsession seinem Team als Ansprechpartner zu fachlichen Fragen dienen. Der Entwickler versucht nun aus dem Blickwinkel des späteren Anwenders die bisher umgesetzten Anwendungsbereiche zu verwenden und stellt Fragen, sobald ihm bei der Verwendung der Anwendung etwas unklar erscheint. Diese Art von Test kann meist erst bei einem fortgeschrittenen Entwicklungsstand durchgeführt werden. Umgang mit Test Session Findings Nach einer durchgeführten Testsession werden parallel in jedem Entwicklungsteam die gefundenen Fehler besprochen und gesammelt. Anschließend ist es die Aufgabe der entwicklungsnahen Tester die Ergebnisse aller Teams abzugleichen, Duplikate zu entfernen, Findings zu priorisieren und auf die einzelnen Teams wieder aufzuteilen. Dies setzt voraus, dass die entwicklungsnahen Tester durchgängig einen Überblick auf das Gesamtprojekt und die Zuständigkeiten einzelner Bereiche besitzen. Anzahl Findings Sprint 4.04 (1) Sprint 4.04 (2) Sprint 5.01 Sprint 5.02 Sprint 5.03 Sprint 5.04 Sprint 6.01 Fazit Es ist nie zu spät neue Prozesse zur Qualitätssicherung auch in bestehende Projekte zu integrieren. Im Jahr 2014 führte die PENTASYS in zwei bereits seit Jahren laufenden Kundenprojekten die beschriebenen agilen Testprozesse ein. Das Ergebnis bei beiden Projekten war eine Entlastung der Entwickler sowie der Product Owner, eine Steigerung der Entwicklungsqualität um 92 Prozent innerhalb der ersten 3 Monaten beim Bank-Projekt und eine Reduzierung der Fehler aus der Produktion um mehr als 70% beim Telekommunikations-Projekt. Die Kunden waren im Stande, jederzeit einen funktionierenden Entwicklungsstand vorzuzeigen, was zum Beispiel PENTASYS Blickpunkte - Agile entwicklungsnahe Testprozesse 3

6 Agile entwicklungsnahe Testprozesse beim Bank-Projekt vor der Einführung agiler Testmethoden eine mehrwöchige Stabilisierungsphase voraussetzte. Durch die agilen entwicklungsnahen Tester wird die Chance deutlich erhöht, den typischen Herausforderungen agiler Projektvorgehensmodelle erfolgreich begegnen zu können. Neben einer pragmatischen und effektiven Arbeitsweise sind verschiedene Parameter für ein erfolgreiches agiles Testen verantwortlich: Teamdynamik, eine frühe Integration von Entwicklern und Testern, das Schaffen von Synergien sowie Synchronisation zwischen Entwicklung und Test, ein exzellentes Fachwissen der Tester, die Identifikation der Tester mit pragmatischen, agilen Vorgehensweisen sowie eine mit Augenmaß ein- und durchgeführte Testautomatisierung. Bei der Einführung einer agilen Methode sollte ein Tester gesucht werden, der offen und kommunikativ ist. Jemand, der nicht nur Testfälle schreibt und ausführt, sondern Spaß daran hat Konzepte, Ideen und Strategien zur Qualität des Gesamtprojekts mit zu entwickeln und schon bei der Anforderungsspezifikation unterstützt. Beim Scrum-Team muss ein Arbeitsplatz für den Testers geschaffen werden. Falls dies räumlich nicht möglich ist (z. B. bei off shore-entwicklung), können Videokonferenz und Messenger-Tools eingesetzt werden. Der Tester wird in Dialog mit dem Kunden/Anforderungssteller durch die Teilnahme an Story Time und Estimation Meetings gebracht, um eine Business- bzw. Anwendersicht zu bekommen. Durch Nachfragen und Diskussion fördert der Tester die Kommunikation unter den Entwicklern. Diese betrachten Tester dadurch als Teammitglied und nicht als Abteilung QS. Quellen [1] Tricks-Techniques/dp/ [2] Die Autoren Björn Mallmann ist IT-Consultant bei der PENTASYS AG mit Fokus auf agiler Qualitätssicherung von Softwarelösungen im Bereich Financial Services. Er ist ISTQB Certified Tester und ISQI Certified Professional for Project Management. Sein Masterstudium schloss er mit dem Schwerpunkt Anwendung und Management von Informationssystemen ab. Joseph Kana arbeitet als Line Manager und Quality Manager bei der PENTASYS AG. Er verfügt über langjährige praktische Erfahrung im Bereich der Software-Qualitätssicherung. Er ist auf die Bereiche Testmanagement, Mobile und Agile Testing fokussiert. Er ist ISTQB Certified Tester Foundation Level Extension Agile Tester. Neben dem Coaching von Projekten in allen Bereichen der Qualitätssicherung führt er in mehreren agilen Projekten agile Testmethoden ein. Die Blickpunkte sind ein kostenloser Newsletter der PENTASYS AG. Die PENTASYS AG, mit Sitz in München und Geschäftsstellen in Frankfurt am Main, Nürnberg, Köln, Stuttgart und Hamburg, ist ein Tochterunternehmen der französischen AUSY Group, die Mitarbeiter in 11 Ländern beschäftigt. Das Beratungs- und Systemhaus ist seit 20 Jahren darauf spezialisiert, Geschäftsprozesse durch kundenspezifische IT-Lösungen zu optimieren. Leistungsschwerpunkte sind Projektmanagement, Anforderungsanalyse, IT-Architektur, agile Entwicklung, Test und Qualitätsmanagement. PENTASYS ist ISO-9001/2008 zertifiziert und beschäftigt heute ca. 500 Mitarbeiter. Zu den Referenzkunden gehören u.a. namhafte Unternehmen aus den Branchen Automotive, Financial Services, Telecommunication sowie Travel, Transport & Logistics. PENTASYS AG Rüdesheimer Straße München Tel.: PENTASYS AG. Stand April 2016 Sämtliche Inhalte des Newsletters, auch Konzepte und Design, sind urheberrechtlich geschützt. Das Copyright/Urheberrecht liegt bei der PENTASYS AG. redaktion@blickpunkte.de