BOOKLET AGILES TESTEN QUALITÄTSSICHERUNG IN AGILEN PROJEKTEN. Copyright 2015 bbv Software Services AG

Transkript

2 PROFITIEREN SIE VON UNSERER ERFAHRUNG! Kontakt Schweiz bbv Software Services AG Blumenrain Luzern Telefon: Kontakt Deutschland bbv Software Services GmbH Agnes-Pockels-Bogen München Telefon: info@bbv.eu Der Inhalt dieses Booklets wurde mit Sorgfalt und nach bestem Gewissen erstellt. Eine Gewähr für die Aktualität, Vollständigkeit und Richtigkeit des Inhalts kann jedoch nicht übernommen werden. Eine Haftung (einschliesslich Fahrlässigkeit) für Schäden oder Folgeschäden, die sich aus der Anwendung des Inhalts dieses Booklets ergeben, wird nicht übernommen. 2 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

3 INHALT 1 Einleitung 5 2 Agile Softwareentwicklung 7 3 Rollen und Verantwortlichkeiten 9 4 Automatisierung Automatisierungsstrategie Unit-/Komponententest Acceptance-Test/API-Layer-Tests Systemtest/GUI-Test Explorativer Test Manueller Test Beispiele Weiterentwicklung einer bestehenden Lösung bbv Testautomation Framework (TAF) 18 5 Testplanung Qualitätsziele Teststrategie Testplan 25 6 Profil des agilen Softwaretesters 27 7 Testaktivitäten im Ablauf einer Iteration Releaseplanung/Pre Planning Iterationsplanung Umsetzung Produktrelease User-Akzeptanz-Test (UAT) Feedback 32 8 Erfolgsfaktoren Whole-Team-Approach 35 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 3

5 1 EINLEITUNG Software wird heute vielerorts nach agiler Entwicklungsmethodik erstellt: Unter Einbindung des Auftraggebers entsteht in sehr kurzen Iterationszyklen die Applikation, die seine Bedürfnisse befriedigt. Auf langwierige, getrennte Phasen der Anforderungsdefinition, Implementation und Qualitätssicherung wird verzichtet. Der Auftraggeber soll rasch lauffähige und getestete Software erhalten. So kann er bewerten, ob die erstellte Funktionalität seinen Ansprüchen genügt oder nicht und die Software gegebenenfalls anpassen lassen. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 5

6 Funktionalität wird in Form von User Stories definiert. Agile Engineeringpraktiken wie Test Driven Development (TDD), Extreme Programming (XP) und Continuous Integration (CI) helfen dabei, qualitativ hochwertigen Code zu erstellen und binnen kürzester Zeit neue Releases der entwickelten Software bereitzustellen. Zum vollständigen Prozess der Softwareentwicklung gehören auch die Tätigkeiten, die traditionell der Qualitätssicherung und dem Testing zugeschrieben werden. Im agilen Umfeld erhalten diese eine neue, andere Bedeutung. Die Erstellung von Unit-Tests durch Entwickler während der Implementation alleine genügt schlussendlich nicht, um ein Softwaresystem zu bauen. Auch in agilen Projekten werden Softwaretester benötigt, die mit ihrem Verständnis und Blickwinkel auf Software dazu beitragen, dem Auftraggeber das Produkt abzuliefern, das er braucht, die dem Team helfen zu verstehen, was es implementieren muss, und die dafür sorgen, dass Funktionalität umfassend getestet und in Form von Testfällen beschrieben ist. Das klassische Rollenverständnis von Entwicklung und Test verschwindet das Entwicklungsteam besteht aus Mitgliedern mit unterschiedlichen Fähigkeiten und Auffassungen. Qualität wird zur Teamsache. 6 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

7 2 AGILE SOFTWARE- ENTWICKLUNG In der agilen Softwareentwicklung wird auf schwergewichtige Prozesse mit langen Phasen verzichtet. In kurzen Iterationszyklen von 1 bis 4 Wochen wird neue Funktionalität entwickelt und dem Kundenvorgelegt. Änderungen sollen ohne grossen zeitlichen und formalen Aufwand realisiert werden können. Anforderungen werden daher in Form von User Stories im Product Backlog verwaltet, das der Kunde bzw. der Product Owner laufend ergänzt und neu priorisiert. User Stories beschreiben kurz, welche neue Funktionalität hinzugefügt oder geändert werden soll. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 7

8 Sprint Retrospective Sprint Planning Sprint Review & Demo Daily Scrum Sprint Start Sprint End Abbildung 1: Ablauf einer Iteration am Beispiel von Scrum Der Ablauf einer Iteration wird am Beispiel von Scrum, wie in Abbildung 1 dargestellt, kurz erläutert. Beim Planning Meeting (Scrum: Sprint Planning) zu Beginn einer Iteration (Scrum: Sprint) erläutert der Product Owner gegenüber dem Entwicklungsteam die Details der einzelnen Stories und legt die Akzeptanzkriterien fest. Alle Stories sind mit einer Priorität versehen und werden vom Team in Tasks aufgeteilt und bezüglich ihres Aufwands geschätzt. Daraus ergibt sich das Set der Stories, die das Team in der kommenden Iteration realisieren kann das Iteration Backlog (Scrum: Sprint Backlog). Das Team beginnt anschliessend mit der Umsetzung der Stories. Eine User Story gilt als abgeschlossen («done»), wenn sie gegen ihre Akzeptanzkriterien getestet worden ist und die allgemeinen Qualitätskriterien erfüllt. Am Ende einer Iteration wird bei der Demo (Scrum: Sprint Review & Demo) dem Kunden die implementierte Funktionalität gezeigt und zur Abnahme vorgelegt. Positive und negative Punkte sowie Verbesserungsvorschläge werden vom Team nach der Demo in einer Review-Sitzung (Scrum: Sprint Retrospective) diskutiert. 8 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

9 3 ROLLEN UND VERANTWORT- LICHKEITEN Agile Softwareentwicklungsteams sind selbst- organisiert und darauf fokussiert, dem Kunden das zu liefern, was ihm den grösstmöglichen Nutzen bringt. Durch die intensive Zusammenarbeit entsteht eine starke Bindung zwischen Kunde, Produkt und Entwicklungsteam. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 9

10 Team Auftraggeber Experten Abbildung 2: Rollen und Verantwortlichkeiten Eine klassische Rollenverteilung nach Entwickler und Tester findet hier keinen Platz mehr. Personen mit ihren individuellen Fähigkeiten spielen für agile Teams eine wichtige Rolle jedes Teammitglied bringt sein Expertenwissen ein. Wer die verschiedenen Aufgaben während eines Entwicklungszyklus (Iteration) ausführt, spielt keine Rolle mehr, am Ende müssen sie erledigt sein. Ein Team ist eine Gruppe von Leuten mit Expertenwissen. Dieses geht mit der Zeit auf das ganze Team über und bringt somit allen Nutzen. Tester und Programmierer arbeiten miteinander im gleichen Team. Eine neue Rollendefinition findet statt: 10 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

11 Tester Der Tester ist eine Person mit Spezialwissen bezüglich Qualitätssicherung und Softwaretest. Er ist ein Entwickler, der auf Qualität gegenüber dem Kunden fokussiert ist (Maximierung des Kundennutzens). Testautomatisierungsexperte Der Testautomatisierungsexperte ist ein Experte für Tools und Methoden, die das Automatisieren von funktionalen und nicht funktionalen Tests betreffen. Typischerweise ist ein Testautomatisierungsexperte nicht permanent in einem Projektteam eingesetzt. Er wird für einmalige spezifische Testaufgaben wie beispielsweise für abschliessenden Load- und Performancetest hinzugezogen. Programmierer Der Programmierer ist eine Person, die neue Funktionalität implementiert und produktiven Code schreibt. Scrum Master Die Rolle des Scrum Masters ist spezifisch für die agile Entwicklungsmethodik Scrum. Ein Scrum Master ist verantwortlich dafür, dass der Scrum-Prozess von allen Teammitgliedern korrekt angewandt wird. Er sorgt dafür, dass die Teamleistung maximiert wird, indem er Probleme, die ein Sprintziel betreffen, auszuräumen versucht. Zusätzlich soll er dem Team helfen, als Team besser werden zu können, und dazu beitragen, die Fähigkeiten des Teams als Ganzes zu erweitern. Kundenteam (Scrum: Product-Owner-Team) Das Kundenteam kann sich aus Businessanalysten, Projektleitern und Spezialisten jeder Art zusammensetzen. Es definiert COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 11

12 die gewünschte Funktionalität, pflegt das Product Backlog, formuliert die Testfälle, die für Geschäftsprozesse relevant sind und der Abnahme der Software dienen. Das Kundenteam legt die Akzeptanzkriterien fest und ist der Ansprechpartner für das Entwicklungsteam. Das Kundenteam bestimmt zudem die allgemeinen Qualitätskriterien. Feedback durch Vertreter des Kundenteams kann im Scrum-Prozess zu verschiedenen definierten Zeitpunkten am Ende eines Sprints, eines formalen Releases oder bei Abnahme des Produkts erfolgen. Dem Kundenteam werden folgende Rollen zugeordnet: Product Owner: Diese Rolle ist spezifisch für den Scrum-Prozess. Er ist der Vertreter des Kundenteams gegenüber dem Entwicklerteam, pflegt und priorisiert das Product Backlog und ist verantwortlich für die Abnahme des Produkts als Ganzes, die Ergebnisse am Ende eines Sprints und den Produkterfolg des zu realisierenden Projekts. Stakeholder: Sind die Personen oder Organisationen, die das Projekt finanzieren und daraus einen Nutzen ziehen wollen. Sie liefern dem Product Owner Feedback über Funktionsumfang und Benutzbarkeit des zu erstellenden Produkts. User Group: Ist eine grössere Anzahl von potenziellen Benutzern des neuen Produkts, die normalerweise für User Acceptance Testing herangezogen wird. Feedback von User Groups fliesst in die Gewichtung der allgemeinen Qualitätsziele des zu erstellenden Produkts ein. Senior User: Sind erfahrene Benutzer auf Kundenseite, die schnell und laufend Feedback an den Product Owner und das Entwicklungsteam zu Features und Benutzbarkeit der Software liefern bzw. liefern können. 12 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

13 4 AUTOMATISIERUNG Die Automatisierung verschiedenster Arbeitsabläufe im Entwicklungsprozess und in der Testautomatisierung im Speziellen ist für agile Softwareentwicklungsprojekte von zentraler Bedeutung, da ein agiles Team jederzeit funktionierende, getestete Software freigeben können möchte. Das Funktionieren der Software kann nur durch permanentes, umfassendes Testen sichergestellt werden. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 13

14 Eine umfassende Suite von Regressionstests verschiedenster Teststufen stellt ein unverzichtbares Sicherheitsnetz dar, das es erlaubt, das Risiko von Fehlern bei Codeänderungen zu minimieren. Da die zu testende Funktionalität von Iteration zu Iteration zunimmt und damit auch die Anzahl der Regressionstests stetig zunimmt, ist es bereits nach wenigen Iterationen nicht mehr möglich, die gesamte bestehende Funktionalität gewissenhaft manuell zu überprüfen. Die Automatisierung von Testfällen löst dieses Problem und ermöglicht es, diese beliebig oft auszuführen. Dies schafft dem Tester den Freiraum, die Anwendung zusätzlich mittels explorativem Test zu prüfen. 4.1 AUTOMATISIERUNGSSTRATEGIE Unter Testautomatisierung wird im herkömmlichen Sinn meist die Verwendung eines Automatisierungswerkzeugs zur Ausführung von funktionalen Tests über das GUI verstanden. In einem agilen Projekt werden darin die Automatisierungsaktivitäten über alle Teststufen zusammengefasst. 14 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

15 tests not practical for automation provide acceptance and regression tests find gaps drive development Manual Testing Exploratory Testing System Acceptance Tests and Constraints Tests Executable Specifications Acceptance Test Driven Development Integration Tests (3rd-party components) Unit Test Test Driven Development automatically executed manually executed Abbildung 3: Die agile Testpyramide Die agile Testpyramide, angelehnt an die Automatisierungspyramide nach Mike Cohn, stellt auf einfache und anschauliche Weise dar, wie und wo sich die Tests und die dazugehörigen Automatisierungsaufgaben in einem agilen Projekt verteilen (Abbildung 3). Von zentraler Bedeutung für alle Automatisierungsaufgaben ist ihre Wiederholbarkeit: Automatisierte Tests müssen beliebig oft wiederholbar sein und sollen möglichst oft ausgeführt werden. Eine Continuous- Integration-Umgebung, die automatisch einen kompletten Build erstellt und anschliessend Testfälle verschiedener Teststufen ausführt, bildet dafür eine unerlässliche Grundlage. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 15

16 4.2 UNIT- / KOMPONENTENTEST Das Fundament einer durchgängigen Automatisierungslösung bilden Unit-Tests. Sie werden mit einfachen Werkzeugen immer codenah erstellt (z. B. Test Driven Development) und sind schnell in der Ausführung. Gleichzeitig ergibt sich durch agile Entwicklungsmethodiken wie TDD besser testbarer Code und ein besser testbares Design. Wenn immer möglich sollen Tests auf dieser Stufe ausgeführt werden. 4.3 ACCEPTANCE-TEST / API-LAYER-TESTS In klassischen Projekten ist dies die am schwierigsten zu beschreibende Teststufe (Integrationstest). Die Software bzw. lauffähige Komponenten sollen hier als Ganzes über ihre Schnittstellen getestet werden zum Beispiel direkt unterhalb des GUI. Testfälle sind hier meist schon mit konkreten Werten für Geschäftsvorfälle belegt und in Form von Aktionen und erwarteter Ausgabe aufgelistet und ausführbar. Auf dieser Stufe sollen die Akzeptanzkriterien der User Stories geprüft werden. Mit geeigneten Entwicklungswerkzeugen können diese in einer formalen Form spezifiziert und festgehalten und schlussendlich automatisch ausgeführt werden (executable specifications). 4.4 SYSTEMTEST/GUI-TEST Innerhalb einer Automatisierungslösung sind GUI-Tests die wartungsintensivsten und sie sind am aufwendigsten zu erstellen. Ihre Ausführung dauert im Vergleich zu den anderen Teststufen sehr lange. Doch es gibt Aktionen und Ergebnisse, die das gesamte System inklusive seiner grafischen Schnittstellen betreffen (Systemtest). Daher kann auf sie nicht gänzlich verzichtet werden. Ihre Anzahl sollte aber möglichst klein sein. Nicht funktionale Anforderungen oder Vorgaben, die nicht als Business Requirements bezeichnet 16 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

17 werden können (constraints), lassen sich meist erst mit dem Gesamtsystem prüfen. 4.5 EXPLORATIVER TEST Explorative Tests werden von Testern manuell durchgeführt. Es sollen Inkonsistenzen oder Fehlverhalten bei unberücksichtigten Aktionen entdeckt werden. Vorbedingungen, wie z. B. die Vorbereitung von Datenbankzuständen, sollen hier ebenfalls durch automatische Schritte unterstützt werden. 4.6 MANUELLER TEST Alle Testfälle zu automatisieren ist nahezu unmöglich. Beispielsweise kann der Aufwand zur Automatisierung schlichtweg zu gross sein, oder es kann sich um Testfälle handeln, die nur einmal ausgeführt werden sollen. Eine möglichst klein zu haltende Zahl manueller Tests wird es auch im agilen Projekt immer geben, deren Ausführung jedoch durch automatische Schritte unterstützt werden kann. 4.7 BEISPIELE WEITERENTWICKLUNG EINER BESTEHENDEN LÖSUNG Bei der Umstellung eines laufenden Softwareentwicklungsprojekts auf agile Projektmethoden trifft man meist folgende Situation an: Für den bestehenden Code existieren keine oder kaum Unit-Tests, die Architektur lässt keine API-Tests zu. Zwangsläufig muss hier zu Beginn ein Automatisierungsansatz gewählt werden, der zunächst nur GUI-Testautomatisierung beinhaltet, siehe Error! Reference source not found.. Die wichtigste Funktionalität soll über ein kleines Set von GUI-Testfällen geprüft werden. Im Rahmen der Weiterentwicklung sollen bestehende Codeteile so COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 17

18 umgeschrieben werden, dass der Code mit Unit-Tests versehen wird und die Architektur auch die Erstellung von automatisierten Acceptance-Testfällen unterhalb des GUIs zulässt. So wird mit der Zeit eine Verteilung der Testfälle über Teststufen entstehen, die in der Anzahl der Gewichtung der Automatisierungspyramide entsprechen wird. Keine Automatisierung GUI Tests für Hauptfunktionen Auf- und Ausbau der Testautomatisierung Unit, API und GUI Tests Abbildung 4: Umsetzung der Automatisierungsstrategie BBV TESTAUTOMATION FRAMEWORK (TAF) Wie kann man in einem agilen Projekt einem Testteam helfen, das wenig Automatisierungserfahrung hat und gezwungen ist, gut dokumentierte Systemtests über das GUI auszuführen? Dies kann z. B. im regulierten Umfeld der Fall sein. Es wird eine Lösung benötigt, die auf ein komplexes Automatisierungswerkzeug aufsetzt, seine Komplexität aber verbirgt. Einzelne Aktionen werden in Bausteine gepackt, sodass bei Änderungen an der Software nur wenige dieser Bausteine geändert werden müssen und alle erstellten Testskripte ohne Änderungen 18 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

19 nach wie vor weiterfunktionieren. Schlussendlich werden aus den ausgeführten Tests vollständig dokumentierte Testreports produziert. Das bbv Testautomation Framework (TAF) ist ein Werkzeug, das diesen Ansprüchen gerecht wird. Abbildung 5: Layering im bbv Testautomation Framework (TAF) Script Compiler Test Case Command Test Case Scripts Tester TAF Script TAF Script TAF Script TAF Scripts (Bausteine) Automation Expert Quick Test Script Quick Test Script Quick Test Scripts (Bausteine) COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 19

20 TAF setzt wahlweise auf die Werkzeuge HP-Quick-Test Pro oder Ranorex auf. Einzelne Bausteine, die in Test-Case-Scripts als Befehle zur Verfügung stehen, werden als Quick-Test-Pro (Ranorex)-Scripts implementiert oder als TAF-Script aus Quick-Test-Pro (Ranorex)- Scripts zusammengesetzt. Test-Case-Scripts bestehen aus einer einfachen Aneinanderreihung von Aktionen und haben nicht mehr viel mit einer komplexen Programmiersprache gemein. TAF übersetzt Test-Case-Scripts und ruft die zugehörigen Quick-Test-Pro (Ranorex)-Scripts auf. So ist es auch für Tester ohne Programmiererfahrung möglich, Testfälle relativ einfach zu automatisieren. Ein Automatisierungsexperte wird benötigt, um die Quick-Test-Pro (Ranorex)-Scripts zu pflegen oder neue Bausteine zu erstellen. TAF generiert aus den Testlaufprotokollen von Quick-Test Pro Testberichte als Word-Dokumente. TAF ist gleichzeitig ein Beispiel, wie man bei Automatisierungs-Frameworks eine Domain Specific Language (DSL) entwickelt, um mit einem Keyword-driven Ansatz die Automatisierung von Testfällen zu vereinfachen. 20 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

21 5 TESTPLANUNG Auch im leichtgewichtigen agilen Umfeld macht es Sinn, sich Teststrategie und Testplan zurechtzulegen es reicht nicht, nur zu definieren, dass alle Akzeptanzkriterien erfolgreich getestet sein müssen. Wann sind diese abschliessend getestet und nach welchen Gesichtspunkten soll dies geschehen? COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 21

22 Testing Programmierung Kundenteam Sprint 1 Feedback Sprint 2 Feedback Change Requests, Bugfixes, Wünsche Sprint 3 Feedback Sprint 4 Feedback Testautomatisierung, Explorativer Test Testdesign, manueller Regressionstest Sprint 5 Feedback Sprint 6 Feedback Sprint 7 Feedback Sprint-Demos, Akzeptanztest Unit-Test, automatisiert Sprint 8 Feedback Sprint 9 Feedback Sprint 10 Feedback Release Testaktivitäten Testfälle total automatisierte Testfälle Feature Complete Abbildung 6: Testmanagement im agilen Umfeld Zusätzlich kann es Qualitätsmerkmale geben, die der Kunde speziell priorisiert und die bei Testaktivitäten daher besonders berücksichtigt werden müssen. Strategie und Plan sollen unkompliziert und einfach ausfallen die Planung steht im Vordergrund, nicht der Plan. Abbildung 6 zeigt, wie sich Aufwände bezüglich Planung, Testfallerstellung und Testausführung über mehrere Iterationen (Sprints) auf Kundenteam, Programmierer und Tester verteilen. Die Zahl der Testfälle nimmt zu; durch den Einsatz von Automatisierung verkleinert sich gleichzeitig der manuelle Aufwand zur Ausführung von Testfällen. Beschränken sich die Testaufgaben zu Beginn auf Tests gegen Akzeptanzkriterien, wird mit steigender Zahl automatisierter Testfälle Zeit für explorativen Test frei. Dies macht bei 22 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

23 zunehmender Komplexität der Software und gleichzeitiger zunehmender Testaktivität des Kunden auch Sinn. Quality Functionality Reliability Usability Efficiency Maintainability Portability Suitability Accuracy Interoperability Security Maturity Fault tolerance Recoverability Understandability Learnability Operability Attractiveness Time behaviour Resources Utilisation Analysability Changeability Stability Testability Adaptability Installability Co-existence Repleaceability Abbildung 7: Qualitätsziele nach ISO QUALITÄTSZIELE Um Testaktivitäten gezielt einzusetzen und um damit auch die Entwicklung entsprechend treiben zu können, ist es wichtig, dass für die neu zu erstellende Anwendung bzw. das zu realisierende Projekt Qualitätsziele definiert werden, die speziell beachtet werden sollen. Ist für den Kunden beispielsweise Performance (Time Behaviour) von essenzieller Bedeutung, dann sollten sich auch die Testaktivitäten dahingehend fokussieren. Die Qualitätsziele gilt es auch bei der Festlegung von Akzeptanzkriterien zu User Stories zu berücksichtigen. Zur Auswahl entsprechender Ziele eignet sich beispielsweise das klassische Qualitätsmodell nach ISO COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 23

24 5.2 TESTSTRATEGIE In der Teststrategie werden Überlegungen zu einzelnen Testmethoden, Werkzeugen und Teststufen festgehalten. Es handelt sich um eine Dokumentation, die sehr wenig geändert werden muss und relativ abstrakt den Testprozess in einem Projekt beschreibt. Als Hilfsmittel zur Ableitung einer Teststrategie sollen die durch die Qualitätsziele definierten Qualitätsaspekte berücksichtigt werden, zusätzlich kann die Darstellung der agilen Testing-Quadranten herangezogen werden (Abbildung 7). Eine Teststrategie kann beispielsweise folgende Punkte enthalten: Automatisierungsansatz, Dokumentation von Testresultaten, Testmethodik, Einsatz von Werkzeugen, Bugtrackingprozess, Testumgebungsmanagement, User-Acceptance-Testing, Storytest, explorativer Test etc. Abbildung 8: Die agilen Test-Quadranten nach Crispin/Gregory Automatisiert und manuell Kundenorientiert Manuell Team unterstützen Funktionale Tests Beispiele Story Tests Simulationen Prototypen Unit Tests Komponenten Tests Q2Q3 Q1Q4 Explorativer Test Szenarien Usability Testing UAT (User Akzeptanz Test) Alpha/Beta Test Performance & Load Test Security Test «-ility» Tests Produkt prüfen Automatisiert Technologieorientiert Werkzeuge 24 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

25 Welche Testarten helfen dem Team? Welche unterstützen den Kunden dabei, die Softwarelösung zu erhalten, die ihm den grössten Nutzen bringt? Welche Testarten eignen und lohnen sich für den Einsatz von Automatisierung? Es hängt von den selbst gewählten Vorgaben aller vier Quadranten ab, um Stories abzuschliessen («Definition of done»). 5.3 TESTPLAN Im Testplan gilt es, die Kriterien an Umfang, Priorität und Risiken festzuhalten sowie Annahmen, Umfang und den Fokus des Testansatzes festzulegen. Es wird die angestrebte Testabdeckung kurz und prägnant definiert. erledigt mehr Tests nötig kritische Probleme noch nichts getestet keine Tests nötig Datenkonsistenz Benutzbarkeit Lasttest Randbedingungen Security Unit Tests Abbildung 9: Testplan in Matrixform Reports Buchungen Benutzererfassung Berechtigungssystem Migration Für eine Iteration kann es beispielsweise genügen, Funktionalität und zu testende Ausprägungen in Matrixform gegeneinander auf- COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 25

26 zulisten, wie in Error! Reference source not found. dargestellt. Bei der Planung wird markiert, welche Ausprägung für welche Funktionalität getestet werden muss. Der Testfortschritt kann durch farbliche Markierung getesteter Bereiche visualisiert werden. 26 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

27 6 PROFIL DES AGILEN SOFTWA- RETESTERS Im idealen agilen Softwareprojekt gibt es keine separate Testabteilung mehr. Ebenso hat der Programmierer ausgedient, der einfach Code nach Belieben schreibt und an eine Testabteilung weitergibt. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 27

28 Dies stellt neue Anforderungen an Personen, die in agilen Teams als Spezialisten mit Testwissen tätig sind: Agile Tester müssen mit permanenter Änderung umgehen können: Anforderungen sind nicht mehr von Beginn an fest, sondern ändern sich ständig. Ihre Testaktivitäten sollen für diese ständige Änderung angepasst sein und dafür sorgen, dass das Team besser entwickeln kann. Agile Tester müssen proaktiv und kommunikativ sein. Sie müssen sowohl die technische als auch die Kundensicht verstehen. Agile Tester sind lernfähig und helfen, neue Werkzeuge einzuführen, die die Arbeit vereinfachen und die Entwicklung vorantreiben. Dazu gehört auch, möglichst viele Testaufgaben zu automatisieren. Agile Tester sind nicht länger die «Gate-Keeper». Vielmehr ist es ihre Aufgabe, dem Kunden dabei zu helfen, seine Wünsche in eine Form zu bringen, dass diese vom Entwicklungsteam verstanden werden können. Tester helfen dabei, diese in Form von Testfällen zu dokumentieren und dem Team weiterzugegeben. 28 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

30 7.1 RELEASEPLANUNG/PRE PLANNING Der Tester nimmt an den Pre-Planning-Sitzungen und einer mehrere Sprints vorbereitenden Releaseplanungssitzung teil. Hier diskutiert der Product Owner die Stories, die er am nächsten Planning Meeting präsentiert. Dies versetzt den Tester in die Lage, Testszenarien zu erarbeiten, die er am Planning Meeting einbringt. Nach dem Planning Meeting kann der Testplan abgeschlossen werden. 7.2 ITERATIONSPLANUNG Die Iterationsplanung, also die Planung der nächsten 2 bis 4 Wochen, findet im Planning Meeting statt. Ziel ist es, möglichst alle Unklarheiten im Verständnis der Stories zu beseitigen, die Stories in Tasks aufzuteilen und den Arbeitsaufwand für die Tasks oder die Stories zu schätzen. Aus der Sicht der Tester kommt den Planning Meetings folgende Bedeutung zu Einbringen der Testingsichtweise und Testingüberlegungen bei der Diskussion der Stories und Aufteilung dieser in Tasks. Klärende Details sollen bereits in Form von Testfällen festgehalten werden. Diskussion zur Testbarkeit auf Integrations- und GUI-Testebene. Nach Abschluss des Planning Meeting hat das Team eine klare Vorstellung, welche Testfälle auf Integrations- und funktionaler GUI-Ebene nötig sind. Für fortgeschrittene Teams ist es sogar möglich, einen Grossteil der Testfälle bereits im Planning Meeting vollständig zu definieren. Abschätzen des Testaufwands als Teil des Entwicklungsaufwandes einer Story. Je nach Komplexität kann dieser erheblich grösser sein als der Programmieraufwand. 30 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

31 7.3 UMSETZUNG Nach dem Planning Meeting beginnen die Programmier- und Testaktivitäten. Programmierseitig entsteht neue Funktionalität zusammen mit Unit-Tests (TDD). Damit die Tester nicht bis zum Ende der Iteration warten müssen, bis sie mit explorativem und funktionalem Acceptance-Test beginnen können, sollen erste Stories möglichst schnell umgesetzt werden. Darum sollen, sofern notwendig, mehrere Programmierer mit der Realisierung derselben Story beginnen. Tester sollen ihrerseits schnellstmöglich mit der Realisierung konkreter Testfälle beginnen. Sind die Testfälle sehr früh vorhanden, helfen sie den Programmierern bei der Umsetzung der Story, indem diese bereits alle Variationen von Eingaben für die bearbeitete Softwarekomponente kennen. Während der Entwicklung können die Testfälle zur Prüfung der geänderten oder neuen Funktionalität herangezogen werden. Tauchen während der Umsetzung einer Story Fragen auf, die vom Product Owner beantwortet werden müssen, sollen diese nach dem Prinzip «Power of three» geklärt werden, d. h., nebst Product Owner und Programmierer wird zur Klärung auch ein Tester hinzugezogen. Sind Stories programmierseitig abgeschlossen, sollen Programmierer einen Walkthrough bzw. eine Demonstration gegenüber einem Tester durchführen («Show me»), bevor Code eingecheckt und explorativ und funktional getestet wird oder automatisierte GUI-Tests entstehen. Grundsätzlich arbeiten Tester und Programmierer zusammen, um Umsetzung und Test zu optimieren. 7.4 PRODUKTRELEASE Obwohl am Ende einer Iteration potenziell auslieferbare Software vorliegt, gilt es, einen Softwarerelease speziell zu beachten, den Produktrelease. Grundsätzlich kann hierfür die Iteration vor dem Release verwendet werden. In dieser Phase gilt es, Testaktivitäten COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 31

32 wie User-Akzeptanz-Test, finaler Abnahmetest, Regressionstest oder Load- und Performancetests durchzuführen oder abzuschliessen, Dokumentationen und Handbücher zu vervollständigen und vor allem Projektmetriken, wie umgesetzte User Stories, Kosten und Zeitplan, auszuwerten, um festzustellen, ob ein Projekt bislang ein Erfolg war oder nicht. In dieser Phase sollte darauf verzichtet werden, angefangene Stories zu beenden oder Bugs zu reparieren, da es die Phase der Releasevorbereitung ist. Dazu gehören unter anderem Testaktivitäten wie Installationstests oder Kompatibilitätstests bei Datenmigrationen. 7.5 USER-AKZEPTANZ-TEST (UAT) Beim User-Akzeptanz-Test (UAT) wird neue Funktionalität von einem grösseren Benutzerkreis oder einem ausgewählten Kundenteam getestet. Funktionale Tests von Benutzerszenarien werden von Kunden manuell mit der vollständig integrierten Software unter möglichst realen Bedingungen und Daten ausgeführt. Meist fällt der UAT kurz vor den Release, weil erst dann die volle Funktionalität einer Software zur Verfügung steht. Das muss aber nicht sein. Grundsätzlich gilt, den UAT so früh wie möglich durchzuführen, um anfallende Änderungswünsche rasch in die Entwicklung einfliessen lassen zu können. 32 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

33 7.6 FEEDBACK Eine der zentralen Aufgaben der gesamten Test- und Qualitätsaktivitäten ist das Generieren von Feedback. Continuous Integration, Unit-Tests und Acceptance-Tests liefern permanent Feedback über den Zustand der Anwendung nach Codeänderungen. Der Product Owner (Scrum) liefert Feedback zur realisierten Funktionalität bei der Abnahme der Sprintergebnisse und lässt dieses direkt ins Product Backlog in Form neuer User Stories einfliessen. Senior User liefern dem Product Owner laufend Feedback zur Benutzbarkeit der Anwendung, bei Bedarf auch direkt dem Entwicklungsteam. Stakeholder liefern ebenfalls dem Product Owner Feedback zum Stand von Software und Projekt, sie sind es auch, die formale Releases freigeben und gutheissen. User Groups liefern beim User-Akzeptanz-Test bzw. durch die Nutzung des neuen Systems Feedback. Ihr Feedback fliesst über Qualitätsziele wieder ins Product Backlog ein. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 33

34 8 ERFOLGSFAKTOREN Nachfolgend sind die aus der Sicht von bbv Software Services AG wichtigsten Faktoren für ein erfolgreiches Integrieren von Testaktivitäten in agilen Softwareprojekten aufgelistet. 34 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

35 8.1 WHOLE-TEAM-APPROACH Das Team als Ganzes ist für die Qualität der Software und die damit verbundenen Test- und Automatisierungsaufgaben verantwortlich. Die klassische Trennung in Entwicklung und Test verschwindet. Tester bringen ihr Fachwissen zu Testaktivitäten in das Team ein. 8.2 FEEDBACK LIEFERN UND EINHOLEN Kommunikation und Feedback sind für agile Teams von grosser Bedeutung. Jedes Teammitglied trägt mit seinem Fachwissen zur Umsetzung von Stories und zur Klärung von Kundenanforderungen bei Tester eignen sich besonders gut für Letzteres. Sie müssen daher wie alle anderen Entwickler vollständig ins Team integriert sein, um ihre Sichtweise bei der Beurteilung von Stories und der Lösung von Problemen einbringen zu können. 8.3 REGRESSIONSTESTS AUTOMATISIEREN Die Automatisierung von Testfällen schafft das Sicherheitsnetz, das rasch das Funktionieren der Software nach Änderungen bewerten kann, das Risiko von Fehlern nach Änderungen minimiert und Testern den Freiraum schafft, ihre Fähigkeiten bestmöglich einzusetzen. 8.4 KUNDEN EINBINDEN Tester eignen sich hervorragend, um als Bindeglied zwischen Entwicklungsteam und Kunden zu fungieren und den Kunden so entsprechend in die Umsetzung des Softwareprojekts einzubinden. Tester denken mehrheitlich aus Kundensicht. Ihr Fachwissen kann dem Kunden helfen, seine Wünsche zu formulieren. Gleichzeitig können Tester mit dem Kunden Benutzerszenarien und Beispiele erarbeiten, die anschliessend in ausführbare Testfälle übersetzt werden können. COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 35

36 8.5 ÜBERBLICK BEHALTEN Tester haben in der Regel den Überblick über die entwickelte Software als Ganzes, Programmierer sind meist auf die Story fixiert, die sie bearbeiten. Der Programmierer tendiert eher dazu, seine Arbeit als beendet zu betrachten, wenn sein Code funktioniert, während der Tester meist durch seinen Blick für das Softwaresystem als Ganzes eine umgesetzte Story auch mit Sonderfällen zu berücksichtigen weiss. 36 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

38 9.1 AUTOR Urs Müller ist Spezialist für Testautomatisierung und Agiles Testen bei bbv Software Services AG. Als Testautomatisierer und Tester hat er in den vergangenen Jahren in verschiedenen agilen Projekten gearbeitet. Urs Müller ist M. Sc. ETH in Informatik, Certified Scrum Master (CSM) und ISTQB /SAQ Certified Software Tester Advanced Level. 9.2 REFERENZEN [1] Agile Testing, Lisa Crispin, Janet Gregory, Addison-Wesley, 2009 [2] Succeeding with Agile, Mike Cohn, Addison-Wesley, COPYRIGHT 2015, BBV SOFTWARE SERVICES AG

40 bbv Software Services AG ist ein Schweizer Software- und Beratungsunternehmen, das Kunden bei der Realisierung ihrer Visionen und Projekte unterstützt. Wir entwickeln individuelle Softwarelösungen und begleiten Kunden mit fundierter Beratung, erstklassigem Software Engineering und langjähriger Branchenerfahrung auf dem Weg zur erfolgreichen Lösung. Beratung Engineering ERFOLG Lösungen Ausbildung Unsere Booklets und vieles mehr finden Sie unter MAKING VISIONS WORK.