BOOKLET SOFTWAREQUALITÄT IN AGILEN PROJEKTEN. Copyright 2016 bbv Software Services AG

Größe: px
Ab Seite anzeigen:

Download "BOOKLET SOFTWAREQUALITÄT IN AGILEN PROJEKTEN. Copyright 2016 bbv Software Services AG"

Transkript

1 BOOKLET SOFTWAREQUALITÄT IN AGILEN PROJEKTEN Copyright 2016 bbv Software Services AG

2 AGILES TESTEN QUALITÄTSSICHERUNG IN AGILEN PROJEKTEN PROFITIEREN SIE VON UNSERER ERFAHRUNG! INHALT 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. 1 Einleitung 5 2 Agile Softwareentwicklung 7 3 Rollen und Verantwortlichkeiten 9 4 Automatisierung Test-Driven Development (TDD), Test-First Acceptance-Test-Driven Development (ATDD) Behaviour-Driven Development (BDD) Data-Driven Testing (DDT) / Keyword-Driven Testing (KDT) Model-Driven Software Development (MDSD) Automatisierungsstrategie Unit-/Komponententest Acceptance-Test/Api-Layer-Tests Systemtest/Gui-Test Exploratives Testen Beispiele 23 5 Testplanung Qualitätsziele Teststrategie Testplan Teststatusreport 29 6 Profil des agilen Testers 30 7 Testaktivitäten in einer Iteration Release-Planung und Pre-Planning Iterationsplanung Umsetzung The End Game User-Akzeptanz-Test (UAT) 36 2 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 3

3 AGILES TESTEN QUALITÄTSSICHERUNG IN AGILEN PROJEKTEN 1 EINLEITUNG 7.6 Feedback 37 8 Erfolgsfaktoren Das ganze Team ist verantwortlich Sammeln und liefern Sie Feedback Automatisieren Sie Regressionstests Behalten Sie den Überblick Führen Sie bei Bedarf Ruhesprints ein Nutzen Sie agile Kernpraktiken Binden Sie den Kunden mit ein Seien Sie als agiler Tester frühzeitig dabei 41 9 Anhang Autor Referenzen 43 Software ist in unserer heutigen Gesellschaft nicht mehr wegzudenken. Verkürztes Time-to-Market bei hoher Softwarequalität sind heute entscheidende Erfolgsfaktoren. Dies hat erhebliche Auswirkungen auf die Softwareentwicklung: Heutzutage wird die Meinung vertreten, dass sequenzielle (nicht agile) Modelle, wie z. B. das Wasserfallmodell oder das V-Modell, durch ihre fixen, getrennten Phasen nicht flexibel genug oder zu schwergewichtig seien, um bei einer Neuentwicklung im dynamischen Markt standzuhalten. Iterative (halb agile) Modelle, wie z. B. das Spiralmodell oder Rational Unified Process (RUP), verfeinern und ergänzen schrittweise die grobe Ausgestaltung des Gesamtsystems durch kurze Wiederholungen von Coding- und Testphasen. Oft verzichten Unternehmen jedoch bewusst und gänzlich auf starre Phasen. Mittlerweile ist ein eindeutiger Trend zu rein agilen Vorgehensmodellen wie Scrum zu verzeichnen. Der Auftraggeber erhält regelmässig in kurzen Zyklen lauffähige und getestete «Softwarebausteine», bewertet diese und kann situationsabhängig Anpassungen vornehmen lassen. Somit kann er binnen kürzester Zeit auf Marktveränderungen reagieren oder sich bewusst Wettbewerbsvorteile verschaffen. 4 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 5

4 Agile Entwicklungsprojekte verändern jedoch auch das Testen von Softwareprodukten meist als «Agiles Testen» bezeichnet. Der Fokus liegt dabei in der Einbindung von Testern in agile Entwicklungsprozesse unter Beachtung des agilen Manifests und der Anwendung agiler Prinzipien auf das Testen, wie schnelles Feedback, hoher Automatisierungsgrad, Auflösung starrer Teststufen, enge Zusammenarbeit in selbst organisierten Teams und Vermeidung von Overhead. Das agile Testen erfordert ein «Umdenken» bisheriger «klassischer» Tester, weil die Verantwortung aller Testaktivitäten nun auf das gesamte agile Team verteilt wird. 2 AGILE SOFTWARE- ENTWICKLUNG Ziel der agilen Softwareentwicklung ist es, sich mehr auf die zu erreichenden Ergebnisse (den «Outcome») der Softwareentwicklung zu konzentrieren. Frühzeitig soll für den Auftraggeber ein maximaler wirtschaftlicher Mehrwert (Business Value) erzielt werden. Änderungen sollen ohne grossen zeitlichen und formalen Aufwand realisiert werden können. Doch wie ist dies zu erreichen? Insbesondere bei Tests, die häufig wiederholt werden müssen, wird Testautomation in Form von Regressionstests inklusive nicht funktionaler Tests angeraten, um die Softwarequalität zu sichern. So können Abweichungen in der Systemstabilität frühzeitig erkannt, Testzeiten verkürzt, Tests beliebig oft wiederholt und durchgängig (24/7) durchgeführt werden. Dabei reicht es nicht aus, dass Entwickler nur automatisierte Tests durchführen, um die Qualität eines Softwaresystems sicherzustellen. Moderne agile Entwicklungsteams führen neben Unit-Tests auch Akzeptanztests aus und ergänzen diese durch explorative Tests. Dies erfordert den sinnvollen Einsatz geeigneter Testverfahren, eine gute Test-/Iterations- und Release-Planung und hohe Skills des agilen Testers. Mit diesem Booklet möchte ich Ihnen kurz die wesentlichen Highlights und Erfolgsfaktoren des Testens in agilen Projekten am Beispiel des Vorgehensmodells Scrum näherbringen. Zunächst werden die Anforderungen in Form von User Stories priorisiert und im Product Backlog verwaltet. Alle Stories werden vom Team analysiert, in Tasks aufgeteilt und bezüglich ihrer Aufwände geschätzt. Das Team entwickelt nun in in kurzen Iterationszyklen von zwei bis vier Wochen neue oder geänderte Funktionalitäten und legt diese dem Auftraggeber als Ergebnis vor. Agile Engineering-Praktiken wie Test-Driven Development (TDD), Extreme Programming (XP) und Continuous Integration (CI) unterstützen dieses Vorgehen, sodass durch frühe Releases von Kernfunktionalität ein schneller Return of Investment (ROI) erreicht werden kann. 6 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 7

5 Sprint Planning Sprint Retrospective 3 ROLLEN UND VERANTWORTLICHKEITEN Sprint Start Daily Scrum Abbildung 1: Ablauf einer Iteration am Beispiel von Scrum Sprint Review & Demo Sprint End 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. Der Ablauf einer Iteration (Sprint) wird am Beispiel von Scrum, wie in Abbildung 1 dargestellt, erklärt: Beim Planning Meeting (Sprint Planning) erläutert der Product Owner zu Beginn eines Sprints gegenüber dem Entwicklungsteam die Details der einzelnen Stories und legt die Akzeptanzkriterien pro Story fest. Alle Stories sind mit einer Priorität versehen und werden vom Team bezüglich ihres Aufwands geschätzt und in Tasks aufgeteilt. Daraus ergibt sich das Set der Stories, die das Team in der kommenden Iteration (Sprint) realisieren kann das Sprint Backlog. Das Team beginnt anschliessend mit der Umsetzung der Stories aus dem Sprint Backlog. Täglich findet dabei ein max. 15-minütiger Informationsaustausch (Daily Scrum) innerhalb des Teams statt. Eine User Story gilt als abgeschlossen, «Done», wenn sie gegen ihre Akzeptanzkriterien getestet und die Qualitätskriterien erfüllt wurden. Am Ende einer Iteration wird im Sprint Review und der Sprint-Demo dem Auftraggeber 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 (Sprint-Retrospective) diskutiert. 8 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 9

6 Team & Scrum sprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Er ist für die Abnahme des Produkts als Ganzes, die Ergebnisse am Ende eines Sprints und den Produkterfolg des zu realisierenden Projekts verantwortlich. Abbildung 2: Rollen und Verantwortlichkeiten Stakeholder (Kunde) Product Owner Stakeholder sind Personen (z. B. Kunden, Anwender, Manager) oder Organisationen, die das Projekt finanzieren und daraus einen Nutzen ziehen wollen. Sie dürfen keinen Einfluss auf das agile Team ausüben und liefern dem Product Owner Feedback über Funktionsumfang und Benutzbarkeit des zu erstellenden Produkts. Der Product Owner ist für den Erfolg der Produktentwicklung verantwortlich. Ihm allein obliegt die Entscheidung über das Produkt, dessen Funktionalitäten und die Reihenfolge der Implementierung. So balanciert er Eigenschaften, Auslieferungszeitpunkte und Kosten. Als Produktverantwortlicher hält er regelmässig Rück- Der Scrum Master ist dafür verantwortlich, dass Scrum gelingt und von allen Teammitgliedern angewandt wird. Dazu arbeitet er mit dem Entwicklungsteam zusammen. 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, seine Fähigkeiten als Ganzes zu erweitern. Das Team ist eine Gruppe von Experten und für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Das Know-how der individuellen Experten geht mit der Zeit auf das gesamte Team über. Zudem trägt das Team die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Es organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es die User Stories umzusetzen hat. Alle Teammitglieder können vielfältige Aufgaben eines Sprints bearbeiten. Exklusive Rollen wie Tester, Programmierer oder Architekt werden im Team vermieden. Jedes Teammitglied bringt sein Expertenwissen ein. Wer die verschiedenen Aufgaben während eines Entwicklungszyklus (Sprint) ausführt, spielt keine Rolle mehr, am Ende müssen diese Aufgaben erledigt sein. «Agile Tester» im Entwicklungsteam Im Team verschwinden die Grenzen zwischen klassischen Testrollen wie Test Manager, Test Analyst oder Tester. Teilweise verschwimmen auch die Grenzen zwischen Entwickler und Tester. Durch Test- 10 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 11

7 aktivitäten soll die Entwicklung des Systems durch schnelles Feedback abgesichert werden. Die früher angestrebte Unabhängigkeit zwischen Entwickler und Tester wird zugunsten der engen Zusammenarbeit aufgegeben. Um jedoch Fehlerblindheit und zu starke Unbefangenheit des agilen Testers zu vermeiden, sollte die frühere Grenze nicht komplett aufgehoben werden. Beispiele individueller Fähigkeiten der Teammitglieder Softwareentwickler Der Softwareentwickler ist eine Person, die neue Funktionalität implementiert und produktiven Code schreibt inklusive Tests wie Unit-Tests oder Akzeptanztests. Das pure «Verwalten» von Testprozessen und -strategien durch klassische Test Manager passt jedoch nicht mehr so recht ins agile Umfeld. So übernimmt der Test Manager in agilen Projekten eher übergreifende Testaktivitäten, das heisst Testaufgaben, zu denen der agile (embedded) Tester im Scrum Team nicht in der Lage ist (z. B. End-to-End-Tests). Da der Begriff «Test Manager» mit klassischen Vorgehensmodellen in Verbindung gebracht wird, wird zur besseren Unterscheidung der agile Test Manager oft auch als «Test Master» bezeichnet (in Anlehnung an den Begriff «Scrum Master»). Testingenieur Der Testingenieur ist eine Person mit Spezialwissen bezüglich Qualitätssicherung und Softwaretest. Er unterstützt Entwickler, die auf Qualität gegenüber dem Kunden fokussiert sind. Testautomatisierungsexperte Der Testautomatisierungsexperte ist ein Experte für Tools und Methoden, die das Automatisieren von funktionalen und nicht funktionalen Tests betreffen. Typischerweise wird er für spezifische Testaufgaben und/oder permanent im Projektteam eingesetzt. Er stellt auch Anforderungen an Entwickler zur effizienteren Umsetzung der Testautomatisierung. (Nicht agiler) Test Manager vs. (agiler) Test Master Der «nicht agile» Test Manager ist in klassischen Vorgehensmodellen anzutreffen. Generell basiert seine Arbeit auf starren Teststufen, Quality Gates und definierten Testkonzepten. 12 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 13

8 4 AUTOMATISIERUNG Die Automatisierung verschiedenster Arbeitsabläufe des Entwicklungsprozesses im Allgemeinen und in der Testautomatisierung im Speziellen ist für agile Softwareentwicklungsprojekte von zentraler Bedeutung, da ein agiles Team am Ende eines Sprints funktionierende und qualitätsgeprüfte Software freigeben möchte. Die Qualität der Software kann nur durch permanentes, umfassendes Testen sichergestellt werden. Während des Sprints müssen permanent automatisierte Regressionstests lauffähig sein, um als «Sicherheitsnetz» bei Codeänderungen und Refactorings zu dienen. Weil die zu testende Funktionalität von Iteration zu Iteration zunimmt und damit auch die Anzahl der Regressionstests stetig ansteigt, 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 gibt dem Tester Freiraum, die Anwendung zusätzlich mit explorativen Tests zu prüfen. Nicht nur Unit- und Integrationstests, sondern auch System- und Akzeptanztests müssen frühzeitig im Sprint (möglichst zeitgleich mit der Implementierung einer Story oder sogar davor im Sinne von «Test-First») entworfen und automatisiert werden. Wenn entwickelte Softwareteile noch nicht auf Systemebene getestet werden können (was häufig vorkommen kann), muss für den Systemtest eine eigene Story geschrieben werden, um verzögerungsfrei zu testen. 4.1 TEST-DRIVEN DEVELOPMENT (TDD), TEST-FIRST Die testgetriebene Entwicklung, engl. test-first development oder test-driven development (TDD), ist eine Methode, die häufig in der agilen Softwareentwicklung zum Einsatz kommt. TDD erfolgt in Verbindung mit Unit-Tests, Systemtests oder Akzeptanztests. Bei den Unit-Tests wird die Programmierung in Micro-Iterationen wiederholt. Jede Iteration besteht aus drei Hauptteilen: 1. Der Entwickler erstellt zuerst den Test (Greybox-Test) für das bestimmte erwünschte Verhalten einer Unit, für bereits bekannte Fehler oder eine neue Teilfunktionalität. Der ausgeführte Test wird zunächst vom bestehenden Programmcode noch nicht erfüllt, da es diesen noch gar nicht gibt. 14 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 15

9 2. Anschliessend schreibt/ändert der Entwickler den Code mit möglichst geringem Aufwand so lange, bis mit den nächsten Testdurchläufen alle Tests erfolgreich durchgelaufen sind. 3. Nun erfolgt das Refactoring, das heisst, der Code wird «aufgeräumt». Überflüssiger, duplizierter Code wird entfernt oder nach verbindlichen Code-Konventionen ausgerichtet. Im Gegensatz zu klassischen Vorgehensweisen wie Wasserfalloder V-Modell hat TDD den Vorteil, dass durch viele kleine automatisierte Tests die gewünschte Testabdeckung für das Refactoring in der gewünschten Qualität eher erreicht werden kann: Einfache Metriken: Tests werden bestanden oder nicht. Durch Refactoring in kleinen Schritten entstehen weniger Fehler (einfachere Fehlerlokalisierung). Unit-Tests beschreiben gleichzeitig, was das System leisten soll («eine ausführbare Spezifikation»). Durch die stärkere Modularisierung des Codes kann dieser leichter geändert oder gewartet werden. Trotzdem darf TDD nicht als Ersatz für andere Testarten betrachtet werden, weil durch TDD nicht alle Fehler aufgedeckt werden können (z. B. Fehler in den Anforderungen, in der Systemintegration oder Usability). TDD mit Systemtests hat nicht mehr das Ziel, dass schriftlich definierte Anforderungen erfüllt, sondern eher das spezifizierte Systemtests bestanden werden. In diesem Fall spricht man vom Acceptance-Test-Driven Development (ATDD). 4.2 ACCEPTANCE-TEST-DRIVEN DEVELOPMENT (ATDD) Die akzeptanztestgetriebene Entwicklung (ATDD) ähnelt zwar der testgetriebenen Entwicklung (TDD), ist jedoch eher ein Kommunikationswerkzeug zwischen Kunden/Anwender, Entwickler und Tester. ATDD soll sicherstellen, dass Anforderungen gut beschrieben sind. Die Tests der ATDD sollen für Nicht-Entwickler lesbar und verständlich sein. Oft werden die testgetriebenen Tests von den akzeptanzgetriebenen Tests abgeleitet. Fehler in den funktionalen/nicht funktionalen Anforderungen können durch TDD oft nicht aufgedeckt werden. Hier empfehlen sich ATDD wie Behaviour-Driven Development (BDD) oder Systemtests. 4.3 BEHAVIOUR-DRIVEN DEVELOPMENT (BDD) BDD (Behaviour-Driven Development) ergänzt TDD und ATDD durch Synthese und Verfeinerung, indem es eine strukturierte Sprache vorgibt, in welcher Businessprozesse beschrieben werden. So wird die Beschreibung eines Features durch ein oder mehrere Beispiele, die das Verhalten korrekt darstellen, verdeutlicht und über diese getestet. Konkret heisst dies, dass im Prinzip auch Stakeholder aus der Managementebene entsprechende Anforderungen definieren können, die dann in sogenannten Szenarios resultieren, also zu konkreten Testfällen werden. BDD verbessert die Lesbarkeit von Features und Szenarien, mit welcher sich auch technisch nicht versierte Stakeholder in das Projekt einbringen können. So lässt sich vermeiden, dass ein Stakeholder mit dem Produkt unzufrieden ist, da das Produkt genau dem entspricht, was er definiert hat. Im BDD gelten folgende Prinzipien: Wende für jede User Story das «Five Why s»-prinzip an, sodass ihr Zweck einen eindeutigen Bezug zu Geschäftsergebnissen erhält. «Denke von aussen nach innen» oder anders formuliert: 16 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 17

10 «Implementiere zunächst nur die Verhaltensweisen, die direkt etwas zu den Geschäftsergebnissen beitragen und minimiere Waste». Beschreibe Verhaltensweisen in Single Notations, die für Domain- Experten, Tester und Entwickler direkt zugänglich sind und verbessere die Kommunikation. Übernehme diese Techniken den ganzen Weg hinunter bis zu den tiefsten Ebenen der Abstraktion der Software, wobei ein besonderes Augenmerk auf der Verteilung des Verhaltens liegen sollte, damit die Evolution der Software günstig bleibt. BDD ist derzeit in aller Munde. Leider wird dabei zu häufig der Fokus nur auf Tools wie Cucumber oder JBehave gelegt. Die BDD-Prinzipien werden so häufig vergessen und missachtet. 4.4 DATA-DRIVEN TESTING (DDT)/ KEYWORD-DRIVEN TESTING (KDT) Das datengetriebene Testen ist eine relativ einfache Technik. Ein Test wird erstellt, parametrisiert und mit variierenden Daten ausgeführt. Positive und negative Testfälle werden mit unterschiedlichen Input-Daten ausgeführt, um die Testabdeckung eines einzelnen Tests zu erhöhen. Das Keyword-Driven Testing (auch Table-Driven Testing, Action- Word Testing) ist eine Technik der Testautomatisierung, die man auch für manuelle Tests verwenden kann. Die hohe Abstraktionsebene von solchen Schlüsselwort gesteuerten Tests verbessert die Wiederverwendbarkeit und die Wartbarkeit von Tests. KDT findet meist in zwei Etappen statt: Zu testende Aktionen/Operationen in der Anwendung oder Anforderungen analysieren Wiederkehrende Aktionen und Abläufe dann in Keywords kapseln Ein einfaches Keyword (eine Aktion auf einem Objekt) wäre z. B. «Eingabe von einem Benutzernamen in ein Textfeld». Ein komplexeres Keyword wäre z. B. «Einloggen». 4.5 MODEL-DRIVEN SOFTWARE DEVELOPMENT (MDSD) Das Model-Driven Software Development, kurz MDSD genannt, dient der Verbesserung der Softwarequalität, der Wiederverwendbarkeit sowie der Steigerung der Effizienz von Softwareentwicklungen. Die Definition formaler Modelle bildet die Basis des MDSD. Als formales Modell wird die vollständige Beschreibung eines abgegrenzten Teils der Software in grafischer oder textueller Notation bezeichnet. Dabei wird aus den formalen Modellen automatisiert lauffähige Software erzeugt. Im Fokus des MDSD liegt die Automatisierung des Softwareentwicklungsprozesses. Somit ist ein Modell, welches lediglich der Analyse, dem Entwurf oder der Dokumentation dient, kein Modell im Sinne des MDSD. Modelle im MDSD sind primär Entwicklungsartefakte für die Generierung des finalen Systems. Gemäss einer dreistufigen Modellhierarchie werden Systemanforderungen in formale Modelle abstrahiert, Modelle zu weiteren Metamodellen und schliesslich Metametamodelle automatisch zu ausführbarem Code transformiert. MDSD bietet die Vorteile, dass sich die Abstraktionsebene für das zu spezifizierende System detaillierter darstellt, eine durchgängige Kommunikation durch domänenspezifische Sprachen (DSL s) möglich ist und sich die Effizienz bei der Softwareerstellung durch die automatisierten Transformationen der erstellten Modelle bis zum generierten Code steigern lässt. Gleichzeitig verringern Modelle die Komplexität in Design und 18 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 19

11 Abbildung 3: Die agile Testpyramide Implementierung, indem Code-Duplizierungen reduziert werden. Zur Beschreibung der Modelle kommt meist UML (Unified Modeling Language) zum Einsatz. 4.6 AUTOMATISIERUNGSSTRATEGIE Unter Testautomatisierung wird im herkömmlichen Sinne meist die Verwendung eines Automatisierungswerkzeugs zur Ausführung von funktionalen Tests verstanden. In einem agilen Projekt erfolgen Automatisierungsaktivitäten über alle «Teststufen». 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 Die agile Testpyramide, angelehnt an die Automatisierungspyramide nach Mike Cohn, stellt auf einfache Weise dar, wie und wo sich die Tests und Automatisierungsaufgaben in einem agilen Projekt verteilen (Abbildung 3). Von zentraler Bedeutung ist, dass automatisierte Tests beliebig oft wiederholbar und 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. 4.7 UNIT-/KOMPONENTENTEST Das Fundament einer durchgängigen Automatisierungslösung bilden Unit-Tests. Sie werden mit einfachen Werkzeugen immer Code nah erstellt und sind schnell in der Ausführung. Gleichzeitig ergibt sich durch agile Entwicklungsmethoden wie TDD testbarer Code und ein testbares Design. Wenn immer möglich sollen Tests auf dieser Stufe ausgeführt werden. 4.8 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. Die Testfälle sind hier auf Basis der Akzeptanzkriterien der User Stories bereits mit konkreten Werten für Geschäftsvorfälle belegt und in Form von Aktionen und erwarteter Ausgabe aufgelistet und ausführbar. Mit geeigneten Entwicklungswerkzeugen können diese in einer formalen Form spezifiziert, festgehalten und schlussendlich automatisch ausgeführt werden (Executable Specifications). 4.9 SYSTEMTEST/GUI-TEST Innerhalb einer Automatisierungslösung sind GUI-Tests die Tests, bei denen erfahrungsgemäss ein hoher Aufwand bei hoher Wartungs- 20 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 21

12 intensität erwartet werden kann, da viele Objekte, Aktionen und Ereignisse über die grafische Schnittstelle (GUI) berücksichtigt werden müssen und die Ausführung im Vergleich zu anderen Teststufen sehr lange dauert. Die Anzahl an GUI-Tests sollte daher möglichst klein gehalten werden. Jedoch kann nicht gänzlich auf sie verzichtet werden, da viele GUI-Elemente oft das gesamte System (Systemtest) betreffen. Nicht funktionale Anforderungen oder Vorgaben, die nicht als Business Requirements bezeichnet werden können (Constrains), lassen sich meist erst mit dem Gesamtsystem prüfen. abgedeckt werden. Ziel ist es, am Ende möglichst das gesamte funktionale Spektrum der Software durch Tests abzudecken 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 EXPLORATIVES TESTEN Beim explorativen Testen (Exploratory Testing) handelt es sich um eine informelle Testtechnik, bei der der Tester das Testdesign während einer Session aktiv kontrolliert, während er diese Tests simultan ausführt. Der Tester verwendet die bei der Testausführung neugewonnenen Informationen, um neue und bessere Tests zu designen. Erfahrungsgemäss kommt exploratives Testen im Scrum Team besonders gut an, da es über die üblichen vorgegebenen Testpläne und Done- Kriterien hinausgeht. Zwangsläufig muss hier zu Beginn ein Automatisierungsansatz gewählt werden, der zunächst nur GUI-Testautomatisierung beinhaltet. Die wichtigste Funktionalität soll über ein kleines Set von GUI-Testfällen geprüft werden. Im Rahmen der Weiterentwicklung sollen bestehende Codeteile so 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 (vorausgesetzt die GUI bleibt weitestgehend unverändert). Dadurch wird mit der Zeit eine Verteilung der Testfälle über Teststufen entstehen, die in der Anzahl der Gewichtung der Automatisierungspyramide entsprechen wird. Exploratives Testen ist simultanes Lernen, Testdesign und Testausführung und ist charakterisiert durch: Abbildung 4: Umsetzung der Automatisierungsstrategie Time-Boxing: Test-Sessions mit fixer Dauer Charter: Schriftliche Mission für den Tester Simultanes Testdesign und Testausführung Einsatz von Heuristiken Keine Automatisierung GUI-Tests für Hauptfunktionen Auf- und Ausbau der Testautomatisierung Unit-, API- und GUI-Tests Das Vorgehen des explorativen Testens ist eher risikoorientiert, statt spezifikationsorientiert, das heisst, die Suche fokussiert sich eher auf mögliche Fehlersituationen, die noch nicht durch bisherige Testfälle 22 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 23

13 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? Testing Programmierung Kundenteam Sprint 1 Feedback Sprint 2 Feedback Change Requests, Bugfixes, Wünsche Sprint 3 Feedback Sprint 4 Feedback Testautomatisierung, Explorativer Test 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 Testdesign, manueller Regressionstest automatisierte Testfälle Feature Complete Abbildung 6: Testmanagement im agilen Umfeld Abbildung 6 verdeutlicht die Verteilung der Testaufwände über mehrere Iterationen (Sprints) zwischen Kunde, Programmierer und Tester. Durch Testautomatisierung wächst zwar die Gesamtanzahl der Testfälle, gleichzeitig sinkt jedoch der Aufwand für Testdesign und die Durchführung manueller (Regressions-)Tests. Während sich in den ersten Sprints die Testaktivitäten lediglich auf die Akzeptanzkriterien beschränken, bleibt mit zunehmender Testautomatisierung mehr Zeit für die Durchführung explorativer Tests, was bei Zunahme des Umfangs und der Komplexität der Software als sehr sinnvoll betrachtet werden kann. Agile Tester sollten beachten, dass User Stories des Product Owners (auf Kundenwunsch) umpriorisiert werden können. Dies muss bei den Testaktivitäten berücksichtigt werden. Teststrategie und Testplan sollten so unkompliziert und einfach wie möglich sein die Planung steht im Vordergrund, nicht der Plan. 24 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 25

14 Anpassungsfähigkeit Installierbarkeit Austauschbarkeit Modularität Wiederverwendbarkeit Analysierbarkeit Modifizierbarkeit Prüfbarkeit Vertraulichkeit Integrität Nachweisbarkeit Verantwortlichkeit Authentizität Ausgereiftheit Verfügbarkeit Fehlertoleranz Wiederherstellbarkeit Übertragbarkeit (Portability) Wartbarkeit (Maintainability) Sicherheit (Security) Zuverlässigkeit (Reliability) ISO Funktionalität (functional suitability) Effizienz (Performance efficiency) Kompatibilität (Compatibility) Benutzbarkeit (Usability) Vollständigkeit Korrektheit Angemessenheit Antwortzeitverhalten Ressourcenverbrauch Kapazität Koexistenz Interoperabilität Angemessenheit Erkennbarkeit Erlernbarkeit Bedienbarkeit Fehlertoleranz ggü. Anwenderfehlern Ästhetik der Benutzeroberfläche Barrierefreiheit Abbildung 8: Die agilen Test-Quadranten nach Crispin/Gregory 5.2 TESTSTRATEGIE Auch im agilen Testen sollten Überlegungen zu einzelnen Testmethoden, Werkzeugen und Teststufen in einer Teststrategie festgehalten werden. Hierbei 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 sollten die durch die Qualitätsziele definierten Qualitätsaspekte berücksichtigt werden. Hierzu kann die Darstellung der agilen Testing-Quadranten herangezogen werden. 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. Automatisiert und manuell Team unterstützen Automatisiert Funktionale Tests Beispiele Story Tests Simulationen Prototypen Unit Tests Komponenten Tests Kundenorientiert Q2Q3 Q1Q4 Technologieorientiert Explorativer Test Szenarien Usability Testing UAT (User Akzeptanz Test) Alpha/Beta Test Performance & Load Test Security Test «-ility» Tests Manuell Produkt prüfen Werkzeuge Zur Auswahl entsprechender Qualitätsziele eignet sich beispiels- weise die Qualitätsnorm ISO (siehe Abbildung 7). Je nach Projekt soll eine Teststrategie folgende Punkte enthalten: zum Beispiel Automatisierungsansatz, Reporting, Testmethodik, Test-Tools, Fehlermanagement etc. Dabei sollte der Testquadrant auf jede User Story angewendet werden, um die optimalen Testarten und Vorgehensweisen zu bestimmen. Welche Testarten 26 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 27

15 letztendlich dem Team und Kunden helfen, den grössten Nutzen zu erzielen, hängt von der gewählten Strategie bzw. den selbst gewählten Vorgaben aller vier Quadranten ab, um Stories abzuschliessen («Definition of Done»). 5.3 TESTPLAN Der Begriff «Testplan» wird oft mit dem Begriff «Testkonzept» gleichgesetzt. Jedoch stellt das Testkonzept eher den statischen Teil und der Testplan den über die Projektlaufzeit eher dynamischen Teil dar. Für ein Scrum Team kann die Existenz eines dynamischen High-Level-Testplans wertvoll sein, damit team-/sprintübergreifende Testaktivitäten stets berücksichtigt werden. Generell wird der Testplan von einem Test Master («agilen» Test Manager) ausserhalb des Scrum Teams erstellt. Abbildung 9: Beispiel eines Teststatusreports 5.4 TESTSTATUSREPORT Für eine Iteration kann es genügen, Funktionalität und zu testende Ausprägungen in Matrixform gegeneinander aufzulisten. Durch farbliche Markierungen gibt der Teststatusreport pro Sprint- Backlog-Item einen kurzen Überblick, welche Funktionalitäten bereits getestet wurden bzw. welche noch zu testen sind, wo es kritische Probleme gibt etc. Zum Ende der Iteration sollten zu jeder User Story die erforderliche Akzeptanzkriterien existieren und alle Testfälle zu diesem Zeitpunkt erfolgreich ausgeführt worden sein (100% Test Success und 100% Test Process). Nach Möglichkeit sollten zum Sprint-Ende auch alle gefundenen Bugs pro Item beseitigt worden sein (Zero-Bug- Strategie). Der regelmässige Aushang des Teststatusreports im Team-Büro ist enorm wichtig. So erhalten alle Teammitglieder und Stakeholder während des Sprints eine höhere und plakative Transparenz über den aktuellen Teststatus. 28 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 29

16 6 PROFIL DES AGILEN TESTERS In einem idealen agilen Softwareprojekt gibt es keine separate Testabteilung mehr. Ebenso entfallen die klassischen Testrollen wie Test Manager, Test Analyst oder Tester. Die dedizierte exklusive Rolle des Programmierers, der einfach Code nach Belieben schreibt und an eine Testabteilung weiterreicht, hat ausgedient. Aber was unterscheidet nun den agilen Tester vom klassischen Tester? Welche Fähigkeiten und Kenntnisse braucht ein agiler Tester? Agile Vorgehensweisen stellen neue Anforderungen an Tester, die in agilen Entwicklungsteams als Experten mit Testing-Know-how tätig sind: Agile Tester unterstützen eine hohe Kundenzufriedenheit durch eine enge Zusammenarbeit mit dem Product Owner (Kunden), insbesondere in Bezug auf Akzeptanzkriterien. Sie können somit die qualitativen Auswirkungen von Änderungen besser nachvollziehen; sorgen für eine hohe Softwarequalität, durch Unterstützung des Entwicklerteams in Bezug auf gemeinsames Pair-Testing, konsequente Fehlerprävention und frühzeitige Fehlerfindung; unterstützen eine hohe Entwicklungsgeschwindigkeit, durch Reduktion von Waste (unnötige Testdokumentation, unnötige Fehlerkorrekturarbeiten); sind Teil eines selbst organisierten Teams und unterstützen dieses durch kontinuierliches Feedback und Face-to-face Kommunikation; sind Coaches, die dem Team helfen, durch geeignete Testmethoden sinnvoll, nachhaltig und gut zu testen. Je besser die Tests, umso eher steigt die Softwarequalität; reagieren sehr schnell auf Änderungen, die durch die kurzen Iterationen ermöglicht werden; besitzen eine hohe Teammotivation; berücksichtigen, je nach Umfeld, darüber hinaus aber auch die Werte aus klassischen Vorgehensmodellen (z. B. gute Planbarkeit, Rückverfolgbarkeit, Nachweisbarkeit der Testaktivitäten, systematisches Testen mit hoher Testabdeckung). 30 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 31

17 7 TESTAKTIVITÄTEN IN EINER ITERATION 7.1 RELEASE-PLANUNG UND PRE-PLANNING Obwohl nach jedem Sprint fertige, das heisst «shippable» Software zur Verfügung steht, empfehlen sich optional, je nach Projektgrösse und -komplexität, mittelfristige Veröffentlichungen der Software nach drei bis vier Monaten, also erst nach mehreren Sprints, weil beispielsweise: noch User Stories fehlen, die erst im Zusammenspiel mit anderen bereits umgesetzten User Stories den wahren Business Value für den Kunden generieren; der Kunde basierend auf der Produktvision nicht regelmässig, sondern selbst den geeigneten Zeitpunkt für die Veröffentlichung der Software bestimmen möchte; sich der Aufwand durch permanente Neukonfigurationen des Systems erhöht und durch Fehlkonfigurationen die Stabilität laufender Geschäftsprozesse erheblich gefährdet wird. Aufgrund dessen nimmt der agile Tester an der alle drei Monate stattfindenden Release-Planungssitzung teil, in der die höchstpriorisierten Entwicklungsvorhaben durch alle beteiligten Teams konkretisiert, auf Abhängigkeiten zwischen den Teams geprüft und auf die Sprintziele der einzelnen Teams verteilt werden. Der Product Owner erstellt hieraus den resultierenden Release- Plan, der eine Übersicht über den Zeit- und Kostenrahmen und Termine für Zwischenergebnisse und Fertigstellung beinhaltet. Grob enthält er die Reihenfolge der Umsetzung der Anforderungen und die erwartete Anzahl Sprints. Die Anzahl Sprints ist dabei abhängig von der Entwicklungsgeschwindigkeit (Velocity) des Teams. Diese wird in Story Points gemessen. Anhand der Velocity und der Aufwandsschätzungen des Teams ergibt sich dann, wie viele User Stories das Team innerhalb eines Sprints umsetzen kann. Der Release-Plan wird vom Product Owner in jedem Sprint aktualisiert. 32 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 33

18 In der Pre-Planning-Sitzung diskutiert der Product Owner mit dem Team/agilen Tester vorab die User Stories, die er im nächsten Planning Meeting, zu Beginn des nächsten Sprints, präsentieren möchte. Dies versetzt den agilen Tester vorab bereits in die Lage, neue Testszenarien zu erarbeiten und Akzeptanzkriterien zu neuen User Stories mit dem Product Owner gemeinsam abzustimmen. Er kann diese dann im nächsten Planning Meeting einbringen. 7.2 ITERATIONSPLANUNG Die Iterations-/Sprintplanung, also die Planung der nächsten zwei bis vier 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 des Testers bedeutet dies: Einbringen der Sichtweise und Überlegungen des Testes bei der Diskussion um Stories und deren Aufteilung in Tasks. Klärende Details bereits in Form von Testfällen festhalten. «Design for Test» auf Integrations- und funktionaler GUI-Testebene prüfen. Abschätzen des Testaufwands als Teil des Entwicklungsaufwands einer Story. Je nach Komplexität kann dieser erheblich grösser sein als der Programmieraufwand. Ergebnis: Nach Abschluss des Planning Meetings hat das Team eine klare Vorstellung, welche Testfälle nötig sind, oder es kann diese bereits im Planning Meeting vollständig definieren. 7.3 UMSETZUNG Nach dem Planning Meeting beginnen die operativen Programmier- und Testaktivitäten. Programmierseitig entsteht neue Funktionalität zusammen mit Unit-Tests. Damit die Tester nicht bis zum Ende der Iteration warten müssen, bis sie mit den explorativen, funktionalen und nicht funktionalen Acceptance- Tests beginnen können, sollten erste Stories möglichst schnell umgesetzt und testbar sein. Tester beginnen ihrerseits schnellstmöglich mit der Realisierung konkreter Testfälle. Sind die Testfälle sehr früh vorhanden, helfen sie den Programmierern bei der Umsetzung der Story, sodass 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, werden diese nach dem Prinzip «Power of Three» geklärt, das heisst Tester, Product Owner und Programmierer lösen gemeinsam vor Ort die Problematik einer Story. Sind Stories programmierseitig abgeschlossen, führen Programmierer einen Walkthrough bzw. eine Demonstration gegenüber dem Tester durch («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 gemeinsam zu optimieren. 7.4 «THE END GAME» In agilen Kreisen wird die Zeit kurz vor Produktionseinführung oft «End Game» genannt. «The End Game» beschreibt die Zeit vor dem «Live-Betrieb», in der die letzten Testaktivitäten wie 34 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 35

19 User-Akzeptanz-Test (UAT), finale Abnahmetests, Regressionstests oder nicht funktionale Test wie Load- und Performancetests durchzuführen respektive vor dem endgültigen Rollout abzuschliessen sind. Dokumentationen und Handbücher sind zu vervollständigen. In dieser letzten Phase vor dem Rollout sollte darauf verzichtet werden, noch unkritische Fehler zu beheben oder neue Stories zu beginnen, weil es dadurch unter Umständen zu erneuten Fehlern kurz vor der Produktionseinführung kommen kann. Planen Sie ausreichend zeitliche Reserven für das End Game ein und nutzen Sie diese Rollout-Vorbereitungszeit für Testaktivitäten wie abschliessende integrative und explorative Tests, Installationstests, Datenbankupdates, Datenkonvertierungen oder Kompatibilitätstests (bei Datenmigrationen). Führen Sie einige End-to-End-Szenarien durch und fokussieren Sie Ihren Blick auf die Softwarequalität des Gesamtsystems. Beachten Sie zudem, dass im Rahmen des Continuous Deployments, das heisst mit Auslieferung des ersten Releases an den Kunden, Themen wie Setup, Installer, Berechtigungen, Zertifikate, Updates, Patches etc. geklärt sein müssen. 7.5 USER-AKZEPTANZ-TEST (UAT) Beim User-Akzeptanz-Test (UAT) wird neue Funktionalität von einem grösseren Benutzer-/Kundenkreis getestet. Funktionale Tests von Benutzerszenarien werden vom Kunden manuell mit der vollständig integrierten Software unter möglichst realen Bedingungen und Daten ausgeführt. 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. Und dies ist ein zentraler Punkt: Ein Feature darf nur dann «Done» sein, wenn der UAT erfolgreich war, das wird auch laufend in den Sprints angewendet. Der UAT beim End Game ist schliesslich die letzte Bestätigung der vorangegangenen UATs. 7.6 FEEDBACK Eine der zentralen Aufgaben der gesamten Test- und Qualitätsaktivitäten ist das Generieren von Feedback: Agile Tester liefern permanent Feedback zu Abweichungen in der Softwarequalität. 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. 36 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 37

20 8 ERFOLGSFAKTOREN Nachfolgend sind die aus Sicht der bbv Software Services AG wichtigsten Faktoren für ein erfolgreiches Integrieren von Testaktivitäten in agile Softwareprojekte aufgelistet. 8.1 DAS GANZE TEAM IST VERANTWORTLICH Seien Sie sich als agile Tester bewusst: 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. Sie bringen Ihr Fachwissen zu Testaktivitäten in das Team ein und legen Ihr ursprüngliches Label der «Qualitätspolizei» ab. Sie haben Ihr Agile-Testing Mindset aufgebaut und setzen nun alles daran, dass das Team das Produkt in bestmöglichster Qualität liefert. Entwickler unterstützen Sie dabei und integrieren Sie ins Team. Sie wiederum helfen dem Team bei den Testaktivitäten. 8.2 SAMMELN UND LIEFERN SIE FEEDBACK 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 Sie als agiler Tester eignen sich besonders gut für Letzteres. Sie bringen sich durch Ihre besondere Sichtweise und Ihre Skills bei der Beurteilung von Stories und der Lösung von Problemen ins Team ein. 8.3 AUTOMATISIEREN SIE REGRESSIONSTESTS Durch die Automatisierung der Testfälle schaffen Sie ein Sicherheitsnetz, womit Sie rasch das Verhalten der Software nach durchgeführten Änderungen ermitteln und bewerten können. Sie minimieren somit das Risiko, Fehler aufgrund der Änderungen zu erhalten, und schaffen sich gleichzeitig mehr Freiraum, Ihre Testaktivitäten zum Beispiel durch gezielte explorative Tests zu erweitern. Denken Sie daran: Automatisierte Regressionstests sind eine Teamaufgabe. 38 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 39

21 8.4 BEHALTEN SIE DEN ÜBERBLICK Als Tester haben Sie den Überblick über die entwickelte Software als Ganzes («Big Picture»). Programmierer sind meist auf die Story fixiert, die sie grade bearbeiten und tendieren eher dazu, ihre Arbeit als beendet zu betrachten, wenn der Code funktioniert, während Sie als Tester eine umgesetzte Story auch mit Sonderfällen zu berücksichtigen wissen, um unentdeckte, kritische Fehler zu finden. 8.5 FÜHREN SIE BEI BEDARF RUHESPRINTS EIN Je nach Situation und Anzahl offener Bugs (Priority/Severity) bietet es sich oft an, einen sogenannten «Ruhesprint» (Stabi-Sprint) einzuführen. In diesem Sprint werden dann nur Bugs behoben und KEINE neuen Features implementiert. Generell gibt es Ruhesprints nur in halb agilen oder nicht agilen Projekten 8.6 NUTZEN SIE AGILE KERNPRAKTIKEN Als agiler Tester sollten Sie agile Kernpraktiken nutzen: Continuous Integration (Source-Code sollte mindestens einmal täglich eingecheckt sein, damit etwas testbar ist). Jede Integration durch automatisierte Builds absichern. Agile Tester brauchen ihre eigene, kontrollierbare Testumgebung. Plädieren Sie für eine «Refactoring Iteration» bei zu vielen Fehlern aufgrund technischer Schwierigkeiten. Setzen Sie auf «test-code-test-code-test»-iterationen und testen Sie inkrementell, das heisst, testen Sie zunächst jede kleine Teilfunktion für sich und testen Sie erst danach diese Teilfunktionen sukzessive zusammengefügt. 8.7 BINDEN SIE DEN KUNDEN MIT EIN Als agiler Tester eignen Sie sich hervorragend, um als Bindeglied zwischen dem Entwicklungsteam und dem Kunden zu fungieren. Sie denken aus Kundensicht, sprechen die Domänensprache des Business, gleichzeitig beherrschen Sie jedoch auch die technische Sprache der Entwickler. Durch Ihre spezielle Sicht und Ihr Fachwissen helfen Sie dem Kunden, seine Wünsche zu formulieren. Entsprechend wird der Kunde in die Umsetzung des Softwareprojekts eingebunden. Gleichzeitig können Sie als agiler Tester dem Kunden konkrete Benutzerszenarien und Beispiele veranschaulichen, sodass diese anschliessend in ausführbare Tests übersetzt werden können. 8.8 SEIEN SIE ALS AGILER TESTER FRÜHZEITIG DABEI Tester können viel mehr als nur Fehler finden. Sie haben gute Ideen, können Abläufe optimieren, auf Designfehler hinweisen und gute Empfehlungen zur Optimierung der GUI oder zur Usability geben. Dies ist jedoch nur dann möglich, wenn Sie auch frühzeitig ins Team eingebunden werden und somit rechtzeitig noch Probleme vor dem Rollout erkennen können. Insbesondere agile Tester können bei frühzeitigem Einsatz ihre Regressionstests optimieren bzw. vereinfachen. Somit sind Sie, der agile Tester, ein wertvoller Erfolgsfaktor für den Kunden. Sie sorgen somit für eine hohe Softwarequalität in agilen Projekten, die zu einer hohen Kundenzufriedenheit führt. 40 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 41

22 9 ANHANG 9.1 AUTOR Frank Kayser ist Senior Test Manager und Experte für agiles Testen. Er besitzt langjährige praktische Erfahrung in agilen Projekten. Er ist diplomierter Informatiker (FH), Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), ISTQB Certified Software Tester Advanced Level, IREB Certified Professional for Requirements Engineering und Quality Assurance Management Professional (QAMP). Als Fachleiter des bbv Kompetenzcenters Software-Testing stellt er die Weiterentwicklung von Kompetenzen und Dienstleistungen der bbv Software Services AG durch Innovationsprojekte sicher. 9.2 REFERENZEN [1] Lisa Crispin, Janet Gregory, Agile Testing, Addison-Wesley, 2009 [2] Mike Cohn, Succeeding with Agile, Addison-Wesley, COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 43

23 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.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende

Mehr

Gelebtes Scrum. Weg vom Management hin zur Führung

Gelebtes Scrum. Weg vom Management hin zur Führung Gelebtes Scrum Weg vom Management hin zur Führung Herausforderungen Was ist Scrum? Wer? Pigs Chicken Bild: http://www.implementingscrum.com/ Nein Danke, ich würde da voll drinstecken, aber du wärest

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Was Sie über SCRUM wissen sollten...

Was Sie über SCRUM wissen sollten... Was Sie über SCRUM wissen sollten... +Pluswerk AG Solmsstr.6a 60486 Frankfurt Tel: (089) 130 145 20 Fax: (089) 130 145 10 info@pluswerk.ag Commerzbank Frankfurt IBAN: DE08 5004 0000 0716 6200 00 BIC: COBADEFFXXX

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» «PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» www.pse-solutions.ch ANTOINE DE SAINT-EXUPÉRY 1 PROJECT SYSTEM ENGINEERING

Mehr

07. November, Zürich-Oerlikon

07. November, Zürich-Oerlikon 07. November, Zürich-Oerlikon Individuelles Vorgehensmodell mit dem TFS als Schlüssel zum Erfolg Arpagaus Patrick Bereichsleiter AKROS AG Stricker Mark Software Architekt AKROS AG Agenda Einleitung AKROS

Mehr

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

Mehr

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

Mehr

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ein modellbasierter Prozess für die Anforderungsanalyse im Vorfeld agiler Produktentwicklung

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

Mehr

Projektmanagement in der Spieleentwicklung

Projektmanagement in der Spieleentwicklung Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen Thomas Löchte Geschäftsführer Informationsfabrik GmbH Wir produzieren INFORMATION. Konzeption und Architektur Implementierung [ETL,

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

Meetings in SCRUM. Leitfaden. Stand: 10.11.2014

Meetings in SCRUM. Leitfaden. Stand: 10.11.2014 ^^ Meetings in SCRUM Leitfaden Stand: 10.11.2014 Sitz der Gesellschaften: Cassini Consulting GmbH Bennigsen-Platz 1 40474 Düsseldorf Tel: 0211 / 65 85 4133 Fax: 0211 / 65 85 4134 Sitz der Gesellschaft:

Mehr

WSO de. <work-system-organisation im Internet> Allgemeine Information

WSO de. <work-system-organisation im Internet> Allgemeine Information WSO de Allgemeine Information Inhaltsverzeichnis Seite 1. Vorwort 3 2. Mein Geschäftsfeld 4 3. Kompetent aus Erfahrung 5 4. Dienstleistung 5 5. Schulungsthemen 6

Mehr

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem

Mehr

Projektmanagement Vorlesung 12/ 13

Projektmanagement Vorlesung 12/ 13 Folie 1 Projektmanagement Vorlesung 12/ 13 Prof. Adrian Müller, PMP FH Kaiserslautern phone: +49 6332 914-329 http://www.fh-kl.de/~amueller Folie 2 Inhalte Agile Modelle Manifesto Übersicht XP Prinzipien

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Was sind Jahres- und Zielvereinbarungsgespräche?

Was sind Jahres- und Zielvereinbarungsgespräche? 6 Was sind Jahres- und Zielvereinbarungsgespräche? Mit dem Jahresgespräch und der Zielvereinbarung stehen Ihnen zwei sehr wirkungsvolle Instrumente zur Verfügung, um Ihre Mitarbeiter zu führen und zu motivieren

Mehr

Geyer & Weinig: Service Level Management in neuer Qualität.

Geyer & Weinig: Service Level Management in neuer Qualität. Geyer & Weinig: Service Level Management in neuer Qualität. Verantwortung statt Versprechen: Qualität permanent neu erarbeiten. Geyer & Weinig ist der erfahrene Spezialist für Service Level Management.

Mehr

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

Mehr

Das Wasserfallmodell - Überblick

Das Wasserfallmodell - Überblick Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-41656-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41656-7 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Scaling Scrum Nexus professionell umsetzen

Scaling Scrum Nexus professionell umsetzen Scaling Scrum Nexus professionell umsetzen Frankfurter Entwicklertag 2016 Fahd Al-Fatish Agile Coach, Professional Scrum Trainer Dr. Reinhard Schmitt Organisationsberater und Trainer Skalierung bedeutet

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

Mehr

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Wer bin ich Kurse und Vorträge mit Jeff Sutherland und Ken Schwaber Verschiedene Kurse der Scrum.org Professional

Mehr

Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014.

Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014. Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014. PROJEKT ÜBERBLICK Entwicklung von Fahrerassistenz-Software zur Vorverarbeitung und Fusion von Sensordaten aus

Mehr

Softwareentwicklungsprozess im Praktikum. 23. April 2015

Softwareentwicklungsprozess im Praktikum. 23. April 2015 Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit

Mehr

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software SCRUM bei Festo Frank M. Hoyer, House of Software SI-MS/Frank M. Hoyer Scrum bei Festo 15. März 2010 geändert: 16. September 2014, HOY Was ist SCRUM? Scrum ist ein agiles Framework zur Software-Entwicklung.

Mehr

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013!

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Sie wollen alles über agile Softwareentwicklung wissen? Wie können Sie agile Methoden

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01.

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01. SCRUM Vertragsgestaltung & Vertragsorientierte Projektdurchführung Katharina Vierheilig Vorlesung: Juristisches IT- Agile Softwareentwicklung SCRUM 2 SCRUM Agiles Manifest Individuen und Interaktion Prozesse

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer

Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Inhalt Top Themen Requirements Testen Testautomatisierung Change-Management Risiko-Management Agile Methoden Traceability

Mehr

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

Mehr

Qualitätssicherung. Was ist Qualität?

Qualitätssicherung. Was ist Qualität? Ein Überblick Methoden und Werkzeuge zur Softwareproduktion Was ist Qualität? "Als Qualität eines Gegenstandes bezeichnen wir die Gesamtheit seiner charakteristischen Eigenschaften" Hesse et al. 2 Was

Mehr

Mehr Transparenz für optimalen Durchblick. Mit dem TÜV Rheinland Prüfzeichen.

Mehr Transparenz für optimalen Durchblick. Mit dem TÜV Rheinland Prüfzeichen. Mehr Transparenz für optimalen Durchblick. Mit dem TÜV Rheinland Prüfzeichen. Immer schon ein gutes Zeichen. Das TÜV Rheinland Prüfzeichen. Es steht für Sicherheit und Qualität. Bei Herstellern, Handel

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

DAS TEAM MANAGEMENT PROFIL IM ÜBERBLICK. Sie arbeiten im Team und wollen besser werden. Das erreichen Sie nur gemeinsam.

DAS TEAM MANAGEMENT PROFIL IM ÜBERBLICK. Sie arbeiten im Team und wollen besser werden. Das erreichen Sie nur gemeinsam. Sie arbeiten im Team und wollen besser werden. Das erreichen Sie nur gemeinsam. Das Team Management Profil: Was haben Sie davon? In Unternehmen, die mit dem Team Management Profil arbeiten, entsteht ein

Mehr

Agiles Testen. Handwerkszeug zur Prävention von Fehlern und technischen Schulden. Entwicklertag 2014. Lars Alvincz, Daniel Knapp

Agiles Testen. Handwerkszeug zur Prävention von Fehlern und technischen Schulden. Entwicklertag 2014. Lars Alvincz, Daniel Knapp Agiles Testen Handwerkszeug zur Prävention von Fehlern und technischen Schulden Entwicklertag 2014 Lars Alvincz, Daniel Knapp 2 Agenda Ziel dieses Vortrags Grundzüge des agilen Testens Voraussetzungen

Mehr

Mit agilen Methoden kommen Sie weiter

Mit agilen Methoden kommen Sie weiter Mit agilen Methoden kommen Sie weiter Wir machen Sie und Ihr Unternehmen fit für Scrum. Rido - Fotolia.com Was ist Scrum? Scrum stellt heute eines der bekanntesten agilen Produktentwicklungs-Frameworks

Mehr

HP Software für SAP Solutions

HP Software für SAP Solutions HP Software für SAP Solutions www.hp.com/de/bto HP Software für SAP Solutions SAP ERP 2005: Upgrades warten schon Mit dem ERP (Enterprise Resource Planning)-System SAP R/3 werden unternehmensrelevante

Mehr

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

Arbeiten mit UMLed und Delphi

Arbeiten mit UMLed und Delphi Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf

Mehr

DAS PARETO PRINZIP DER SCHLÜSSEL ZUM ERFOLG

DAS PARETO PRINZIP DER SCHLÜSSEL ZUM ERFOLG DAS PARETO PRINZIP DER SCHLÜSSEL ZUM ERFOLG von Urs Schaffer Copyright by Urs Schaffer Schaffer Consulting GmbH Basel www.schaffer-consulting.ch Info@schaffer-consulting.ch Haben Sie gewusst dass... >

Mehr

[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL

[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL [Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL Was bedeutet Customer Service by KCS.net? Mit der Einführung von Microsoft Dynamics AX ist der erste wichtige Schritt für viele Unternehmen abgeschlossen.

Mehr

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

Kundenbefragung als Vehikel zur Optimierung des Customer Service Feedback des Kunden nutzen zur Verbesserung der eigenen Prozesse

Kundenbefragung als Vehikel zur Optimierung des Customer Service Feedback des Kunden nutzen zur Verbesserung der eigenen Prozesse Kundenbefragung als Vehikel zur Optimierung des Customer Service Feedback des Kunden nutzen zur Verbesserung der eigenen Prozesse Vieles wurde bereits geschrieben, über die Definition und/oder Neugestaltung

Mehr

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Agenda 1. Scope, Motivation und Begriffsklärung 2. Modellierung

Mehr

Agiles Design. Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail: gi@uwe.doetzkies.de

Agiles Design. Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail: gi@uwe.doetzkies.de Agiles Design Dr.-Ing. Uwe Doetzkies Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail: gi@uwe.doetzkies.de startupcamp berlin 15.3.2013 Regionalgruppe Berlin/Brandenburg Arbeitskreis Freiberufler

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Testen im Software- Entwicklungsprozess

Testen im Software- Entwicklungsprozess Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

Scrum Gestaltungsoptionen Empowerment

Scrum Gestaltungsoptionen Empowerment Scrum Gestaltungsoptionen Empowerment WING Zweite Transferkonferenz, 2016-04-06 Matthias Grund, andrena objects ag 2 Scrum-Modell kommt mit (nur!) drei Rollen aus: (crossfunctional) Scrum Owner Owner Scrum

Mehr

Problem-Management und Eskalationsprozess Referenzhandbuch

Problem-Management und Eskalationsprozess Referenzhandbuch TECHNISCHE UNTERSTÜTZUNG FÜR UNTERNEHMEN Problem-Management und Eskalationsprozess Referenzhandbuch Symantecs Verantwortung gegenüber seinen Kunden Symantec bietet Kunden und Partnern hochwertige Produkte

Mehr

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Leseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9. Weitere Informationen oder Bestellungen unter

Leseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9. Weitere Informationen oder Bestellungen unter Leseprobe Thomas Konert, Achim Schmidt Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41230-9 sowie im Buchhandel. Carl

Mehr

conuno - WIR GESTALTEN FÜR SIE Development Services

conuno - WIR GESTALTEN FÜR SIE Development Services conuno - WIR GESTALTEN FÜR SIE Development Services Beratung für Finanzdienstleister Innovative Produktlösungen IT Services & Sourcing c o n s u l t i n g g e s t a l t e n s o f t w a r e g e s t a l

Mehr

Mind Mapping am PC. für Präsentationen, Vorträge, Selbstmanagement. von Isolde Kommer, Helmut Reinke. 1. Auflage. Hanser München 1999

Mind Mapping am PC. für Präsentationen, Vorträge, Selbstmanagement. von Isolde Kommer, Helmut Reinke. 1. Auflage. Hanser München 1999 Mind Mapping am PC für Präsentationen, Vorträge, Selbstmanagement von Isolde Kommer, Helmut Reinke 1. Auflage Hanser München 1999 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 21222 0 schnell

Mehr

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016 Projektmanagement Agile Vorgehensweise / Scrum Version: 1.0 Stand: Lernziel Sie können in eigenen Worten darstellen warum Agilität notwendig ist. Sie können mit eigene Worten das Framework Scrum beschreiben.

Mehr

Softwarequalität: Zusammenfassung und Ausblick. 17. Juli 2013

Softwarequalität: Zusammenfassung und Ausblick. 17. Juli 2013 Softwarequalität: Zusammenfassung und Ausblick 17. Juli 2013 Überblick Rückblick: Qualitätskriterien Qualitätsmanagement Qualitätssicherungsmaßnahmen Thesen zur Softwarequalität Ausblick: Lehrveranstaltungen

Mehr

Was beinhaltet ein Qualitätsmanagementsystem (QM- System)?

Was beinhaltet ein Qualitätsmanagementsystem (QM- System)? Was ist DIN EN ISO 9000? Die DIN EN ISO 9000, 9001, 9004 (kurz ISO 9000) ist eine weltweit gültige Norm. Diese Norm gibt Mindeststandards vor, nach denen die Abläufe in einem Unternehmen zu gestalten sind,

Mehr

BEURTEILUNGS GESPRÄCHEN

BEURTEILUNGS GESPRÄCHEN PERSONALENTWICKLUNG POTENTIALBEURTEILUNG DURCHFÜHRUNG VON BEURTEILUNGS GESPRÄCHEN Beurteilung 5. Beurteilungsgespräch 1 Die 6 Phasen des Beurteilungsvorganges 1. Bewertungskriterien festlegen und bekannt

Mehr

Primzahlen und RSA-Verschlüsselung

Primzahlen und RSA-Verschlüsselung Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

Stuttgart, 25.04.2008 Scrum im Wasserfall... oder wie kann Agilität dem Kunden schmackhaft gemacht werden?

Stuttgart, 25.04.2008 Scrum im Wasserfall... oder wie kann Agilität dem Kunden schmackhaft gemacht werden? Stuttgart, 25.04.2008 Scrum im Wasserfall... oder wie kann Agilität dem Kunden schmackhaft gemacht werden? Hier steht der Titel der Präsentation - Stuttgart, mit Datum Folie 1 dmc besseres E-Business beginnt

Mehr

GEVITAS Farben-Reaktionstest

GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest Inhalt 1. Allgemeines... 1 2. Funktionsweise der Tests... 2 3. Die Ruhetaste und die Auslösetaste... 2 4. Starten der App Hauptmenü... 3 5. Auswahl

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Anforderungsmanagement Wo die Qualität beginnt...

Anforderungsmanagement Wo die Qualität beginnt... Anforderungsmanagement Wo die Qualität beginnt... Anforderungsmanagement Wo die Qualität beginnt... Alexander Weichselberger SEQIS Geschäftsleitung 10 things Veranstaltungen 2013! 21.03. Anforderungsmanagement:

Mehr

Das Ziel ist Ihnen bekannt. Aber was ist der richtige Weg?

Das Ziel ist Ihnen bekannt. Aber was ist der richtige Weg? FOCAM Family Office Das Ziel ist Ihnen bekannt. Aber was ist der richtige Weg? Im Bereich der Finanzdienstleistungen für größere Vermögen gibt es eine Vielzahl unterschiedlicher Anbieter und Lösungswege.

Mehr

Umfrage zum Informationsbedarf im Requirements Engineering

Umfrage zum Informationsbedarf im Requirements Engineering Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine

Mehr

T2 Fundamentaler Testprozess

T2 Fundamentaler Testprozess T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse

Mehr

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität

Mehr

Mit agilen Methoden kommen Sie weiter

Mit agilen Methoden kommen Sie weiter Mit agilen Methoden kommen Sie weiter Wir machen Sie und Ihr Unternehmen fit für Scrum. Was ist Scrum? Scrum ist ein agiles Produktentwicklungs-Framework zur schlanken Entwicklung von Software. Da Scrum

Mehr

Wir helfen Ihnen, sich auf Ihre Kompetenzen zu konzentrieren.

Wir helfen Ihnen, sich auf Ihre Kompetenzen zu konzentrieren. Wir helfen Ihnen, sich auf Ihre Kompetenzen zu konzentrieren. R Unser Anspruch bei bitbase Fokussiert auf Zuverlässigkeit, Qualität und eine permanente Serviceerweiterung tragen wir dazu bei, dass Sie

Mehr

Agile Methoden. David Tanzer. Oliver Szymanski

Agile Methoden. David Tanzer. Oliver Szymanski Agile Methoden David Tanzer Oliver Szymanski Ziel von Softwareentwicklung Anforderungen zuverlässig und effizient in lauffähige Software verwandeln. Ziel von Softwareentwicklung Bedürfnisse des Kunden

Mehr

L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016

L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 Referentin: Dr. Kelly Neudorfer Universität Hohenheim Was wir jetzt besprechen werden ist eine Frage, mit denen viele

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Wie wirksam wird Ihr Controlling kommuniziert?

Wie wirksam wird Ihr Controlling kommuniziert? Unternehmenssteuerung auf dem Prüfstand Wie wirksam wird Ihr Controlling kommuniziert? Performance durch strategiekonforme und wirksame Controllingkommunikation steigern INHALT Editorial Seite 3 Wurden

Mehr

Was macht Layer2 eigentlich? Erfahren Sie hier ein wenig mehr über uns.

Was macht Layer2 eigentlich? Erfahren Sie hier ein wenig mehr über uns. Was macht Layer2 eigentlich? Erfahren Sie hier ein wenig mehr über uns. Seit über 24 Jahren... unterstützen und beraten wir unsere Kunden und Partner erfolgreich bei ihren IT-Projekten. Unsere Kernkompetenz

Mehr

Die wichtigsten Werkzeuge, um UNTERNEHMENSKULTUR BEWUSST zu gestalten.

Die wichtigsten Werkzeuge, um UNTERNEHMENSKULTUR BEWUSST zu gestalten. 3 Die wichtigsten Werkzeuge, um UNTERNEHMENSKULTUR BEWUSST zu gestalten. Rasante Marktverände-rungen und eine ständig wachsende Komplexität beeinflussen heute die Unternehmensentwicklung mehr denn je zuvor.

Mehr

kurzinfo Messen Sie die Innovationsdynamik Ihres Unternehmens. Finden Sie Ansätze und Methoden zur gezielten Weiterentwicklung.

kurzinfo Messen Sie die Innovationsdynamik Ihres Unternehmens. Finden Sie Ansätze und Methoden zur gezielten Weiterentwicklung. kurzinfo Messen Sie die Innovationsdynamik Ihres Unternehmens. Finden Sie Ansätze und Methoden zur gezielten Weiterentwicklung. Sichern Sie so die Zukunftsfähigkeit Ihres Unternehmens. INNONAMICS Stand

Mehr

Engineering Kompetenz ist ein Versprechen.

Engineering Kompetenz ist ein Versprechen. Engineering Kompetenz ist ein Versprechen. In der modernen Zerspanung geht es um mehr als Drehen, Fräsen, Bohren und Gewinden. Perfektion und Präzision sind nur noch Grundvoraussetzung für Ihren Erfolg.

Mehr

Agiles Testmanagement am Beispiel Scrum

Agiles Testmanagement am Beispiel Scrum Agiles Testmanagement am Beispiel Scrum SEQIS Software Testing Know-How Weitere Termine 16. September Testmanagement mit externen Partnern 21.Oktober Software unter Druck: Erfolgsfaktoren bei Last- und

Mehr

Testen mit JUnit. Motivation

Testen mit JUnit. Motivation Test First Design for Test in Eclipse (eigentlich: ) zu einer Klasse Beispiel zur Demonstration Ergänzungen Test First "Immer dann, wenn Du in Versuchung kommst, etwas wie eine print- Anweisung oder einen

Mehr