Agiles Software-Testing

Transkript

1 Agiles Software-Testing Dr. Ferdinand Gramsamer Head of bbv Testing Services

2 Abstract Agiles Software-Testing Wenn ich über agile Software-Entwicklung lese, stolpere ich häufig über Begriffe wie Scrum, TDD, ATDD, BDD, CI, risiko-basiertes Testen, exploratives Testen, Testautomatisierung, o.ä. Ich treffe auch auf Aussagen wie, «die Entwickler müssen nun mehr testen», «Testmanagement braucht es nicht mehr» oder «am besten nimmt man FIT». Doch was steckt dahinter, wie ist das alles zu verstehen, wie hängt das mit agilem Software-Testing zusammen? In meinem Vortrag möchte ich daher aufzeigen, wie diese ganzen Begriffe zusammenhängen und ein einheitliches Ganzes ergeben. Dies wird anhand von Beispielen und gängigen Tools aus der Praxis illustriert. Das Ziel meines Vortrages ist es, mögliche Missverständnisse, die bzgl. agilem Testing existieren, auszuräumen und bei den Teilnehmern ein Verständnis für die richtigen qualitätssichernden Massnahmen für eigene Projekte zu wecken.

3 Zur Person Jahrgang 1969 Studium der Elektrotechnik an der Universität Stuttgart Abschluss 1996 Promotion zum Dr. sc. techn. an der ETH Zürich Abschluss 2003 Wissenschaftlicher Mitarbeiter am IBM Forschungslabor Lead QA-Engineer bei bbv Software Services AG Head of Testing Services bei bbv Software Services AG seit 2007 Zertifikate: ISTQB-FL/AL, CSM, CSPO 5 Patentanmeldungen, 3 Patente Best Paper Award «Useful Metrics in Testing» an CONQUEST 2009 in Nürnberg

4 Mit agiler Software-Entwicklung und Scrum möchte man den ROI und Produktivität steigern Struktur Vorgehensmodell existiert Einhaltung Vorgaben Dokumentation, Tools Einhaltung der Planung Schriftliche Abmachungen Prozesse, Tools Vollständige Dokumentation rigid agil Eingehen auf Veränderung Zusammenarbeit mit Kunden Individuen, Interaktion Funktionierende Software Chaos Abweichungen zu Vorgaben Ohne Vorgehensmodell

5 Software-Testing deckt Fehler auf und zeigt dem Kunden, dass Anforderungen erfüllt sind. Program testing can be used to show the presence of bugs, but never to show their absence. (Dijkstra) The process of executing a programm with the intention of finding errors (Myers, 1976) Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen. (Wikipedia)

6 Was ist ein System Ein Beispiel External Settlement Venue IMIS-ms Market Surveillance Market Data Supplier Trade Reporter MF CDR Issuer Glashaus VDF mds-imis Reference Data Supplier RSD MF-DWH Trade Reporter CDR-DWH rds-4d 4D-iss IMISds rdm-4d_1 Siebel TS-tr_1 ES-esv IMIS SWX / VTX DIDW ES-RSD Reference Data Maintainer ES-DWH DWH IDW RDB 4D-DWH rdm-4d_2 TS-tr_2 TNS.FIX ES-MISds CDW Oracle iss-4d IBL Issuer TS-pt_1 ES-IMIS 4D SIDW 4D GUI Price Taker TNS 4D-ES mds-4d adm-4d TS-pt_2 TS SWX / VTX CLF/CLR FGW SGW EXH IDS IDX RDM TNS.MAPI ES-TS Market Admission Data Supplier Trade Reporter GW ES SWX / VTX ES-TRM ES-OEX EUI ES-CDR OMA mos-es 4D-CDR Market Operations & Supevision TS-tr_3 Price Taker TNA- GUI TNA TS.MAPI ES-FIX rdm-es QPG SGW MFI ES-FIX rdm-cdr Reference Data Maintainer TS-pt_3 ES-SMARTS External Execution Venue QP-TS CDR-SMARTS mds-cdr RC-eev ES-MDS ES-MF Market Data Supplier Trade Reporter ES-RC ES-QP SMARTS CDR CDR GUI CDR-RC RC RC-tr QP-SMARTS broadcast QP-SMARTS CDR-DWH DWH RC-pt Price Taker CDR-QP CDR-MDS CDR-MF FIX FIX OBM MM QP-API ESG native QP-API DSI FIX RC QP-MF RC-RCQPG QMF -FH QMF RCQPG QP FH RC-mos Market Operations & Supevision native QP-API QP-MDS_pre QP-RCQPG FH MDS SMF / QMF (Market Feeds) SWX / VTX SMF FIX FIX SMARTS-ms mds-smarts PEX-MF native QP-API MM QP-API TW native QP-API QP-MDS_post FH FAST RC-propt CDR-RC Proprietary Trader RC-mm QP-mm QP-propt MF-DWH QP-mos MDS-mdc MF-mdv Market Maker CDR Market Maker Proprietary Trader Market Operations & Supevision Market Surveillance Market Data Supplier Market Data Customer Market Data Vendor DWH

7 Warum agiles Testen?

8 Teststufen klassisches Vorgehen V1.0 V1.1 V1.2 V1.3 V1.4 V1.5 V1.6 V2.0 V2.1 V2.2 Entwicklung 2W Comp Int System Comp Int System Comp Int System Potentiell auslieferbare Software Fehler gefunden hier wird hier nachgetestet und hier Fehlerreparaturzyklus ist massgebend: Versatz von ca. 12W

9 Heilmittel Arbeiten mit Patches 2W Comp Int System V1.3 V1.4 Comp Int System Comp Int System Reparaturzyklus: + reduziert auf ca. 6W Risiko erhöht Überlappen von Teststufen Auswirkung: + Verkürzen der Testphasen Arbeiten mit Patches mögl. Reparaturzyklus immer noch lang man kommt sich in die Quere

10 Allheilmittel? Integration von Entwicklung und Test = agiles Testen Auswirkungen V1.0 2W Comp Int System Positiv: Reparaturzyklus verkürzt sich 2W [+] Neue Möglichkeiten für Entwickler, Tests zu nutzen [+] Feedback auch informell möglich (höhere Effizienz) [+] Teamgedanke möglich [+] Aber: Testaufwand steigt [-] Software muss so gebaut werden, dass man sie nach zwei Wochen testen kann [-]. Wie kann man das Testing nun organisieren? Welche Herausforderungen stellen sich nun?

11 Herausforderungen time-boxed Iteratives Vorgehen Zusammenarbeit

12 Mit jedem Sprint arbeitet man auf den Release hin. Die Mission im agilen Testen heisst Feedback.

13 Mit jedem Sprint arbeitet man auf den Release hin. Die Mission im agilen Testen heisst Feedback. Schaue voraus, erkenne die grossen Zusammenhänge Arbeite mit Kunden zusammen Erhalte Feedback Gebe Feedback

14 Automatisiere Regressionstests Angelehnt an die Automationspyramide nach M.Cohn

15 Beispiel: Problem der Wartbarkeit Worum geht s? Coded-UI Tests in Microsoft Visual Studio Automatisierung über das GUI Testcases UITest1.c UITest1.c UITest1.cs s s VB/C# Code: Programmatischer Zugriff auf UI Komponenten UIMap.cs UIMap.Designe r.cs generiert.xml Beschreibung von: UI Komponenten Assert Methoden Capture/Replay UIMap.ui test

16 Engineering-Fragen Testautomatisierung soll auch noch nach Codeänderungen / Änderungen an den Controls laufen. Zugriff auf Properties soll in Testautomatisierung uneingeschränkt möglich sein. UI-Map soll hierarisch sein, um Überblick zu haben UI-Map soll nicht zu gross werden.

17 UI Map: automatische Erstellung, Wrapperschicht Testcases UITest1.cs VB/C# Code: Dispatcher / Snoop UIMap.cs UIMap.Generate d.cs VB/C# Code: Zugriff auf UI Komponenten UIMap.Designer.cs CUITe UIWrappe rs generiert.xml Beschreibung von: UI Komponenten UIMap.uit est Erstellt XML Subtree

18 Fazit Wartungsaufwand für Testautomatisierung gering Kaum Änderungen an Testfällen notwendig Abmachung mit Entwicklung zur Namensgebung der Controls ist Voraussetzung

19 Team Zusammensetzung 1. Testen 1) beim Entwickler 2. Testen beim Entwicklungsteam 3. Rolle des Testers im Entwicklungsteam 4. Dediziertes Testteam pro Projekt 5. Separate Testabteilung (Testen nach Auftrag, Testcenter ) Scrum-team Mitglieder sind T-shaped. Eine T-shaped Person ist - Spezialist in einem technischen Bereich - Hat einen Vertreter, einen Herausforderer, einen Lehrling - Kennt die Domäne 1) Integrations / Systemtest

20 Die Kanten zeigen wem die Tests nützen und die Quadranten welche Methode sich dafür eignet Basierend auf L. Crispin und J. Gregory

21 Die Kanten zeigen wem die Tests nützen und die Quadranten welche Methode sich dafür eignet Erfüllung der Anforderungen (Erwartungen des Kunden) Fehler vermeiden z.b. ATDD Q2 Q4 z.b. TDD Q1 z.b. Risk-based Testing Q3 Nicht-funktionales Testing Fehler finden Erfüllung der Anforderungen (Erwartungen des Betriebs) Basierend auf L. Crispin und J. Gregory

22 Die Kanten zeigen wem die Tests nützen und die Quadranten welche Methode sich dafür eignet Erfüllung der Anforderungen (Erwartungen des Kunden) Fehler vermeiden Verantwortung liegt beim Team z.b. ATDD Q2 Q3 Q4 Agiles Testen Philosophie Programmierer Q1 z.b. TDD z.b. Risk-based Testing Tester Verwendung von Engineering Praktiken Nicht-funktionales Testing Fehler finden Erfüllung der Anforderungen (Erwartungen des Betriebs) Basierend auf L. Crispin und J. Gregory

23 Ziel der Q1 Tests ist interne Qualität / Testbarkeit Toolbox Source Code Management Version Control Integrated development Environment (IDE) z.b. Eclipse, Netbeans, TFS Build / CI-Tools z.b. Hudson, Cruise Control, TeamCity Unit-Test Tools xunit Mocking Tools Was passiert Programmierer testet und codiert Kontinuierliches Refactoring Tests werden mit CI ausgeführt Tests Unit Tests Macht der Code das, was er sollte? Im Interesse des Programmierers Komponenten Tests Arbeiten Komponenten korrekt zusammen? Im Interesse des Architekten

24 Ziel der Q2 Tests: externe Qualität / bauen das Richtige? Toolbox Checklists Mind Maps Paper Prototyps Flussdiagramme Whiteboard BDD / ATDD Fit / FitNesse (BDD) Cucumber, easyb, nbehave (GUI) Selenium, Cucumber, Watir/Watin/Watij, Canoo WebTest, Robot Framework, QTP, Ranorex, QA test, Testcomplete Was passiert Zusammenarbeit mit Kunden Keine Story ist «done», bis sie nicht getestet ist Tests Aus Beispielen werden Tests Abnahme der Story («Smoke Test»)

25 Ziel der Q3 Tests ist das Produkt zu evaluieren Toolbox Wie Q2 Was passiert Demos mit Kunden Prüfen des Produktes Tests Exploratives Testen (Funktion) Prozess Test (Szenarien) Navigation Tests (Usability) Dokumente, Report Tests Schnittstellen Tests Service Tests (z.b. Web-Service) Zugriffsrechte Tests

26 Ziel der Q4 Tests ist den späteren Betrieb sicherzustellen Toolbox jmeter, jconsole, jprofiler TFS-Ultimate Shell-scripts Load-Runner Database Tools Was passiert Einsatzfähigkeit prüfen Vorgehen nach Risiko Eventuell hinzuziehen von Spezialisten Tests Performance Tests Failover Tests Availability Tests Recovery Tests Installations Tests Deployment Tests Daten Migrationstests

27 Risikobasiertes Testen Teststrategie Testobjekte Identifizierung Evaluierung Testing, Review Minderung Analyse Kosten, Wahrscheinlichkeit Bericht Testmetriken Vorhersage

28 Zusammenfassung Verliere nie den Blick auf das Ganze Arbeite mit den Kunden zusammen Erhalte und gebe Feedback Automatisiere Regressionstests Verantwortung liegt beim Team Agile Testing Philosophie Verwendung von Engineering Praktiken Auch Entwickler testen Es braucht auch Tester

29 Danke! Dr. Ferdinand Gramsamer Head of Testing Services