Testen von Software systematisch oder agil?

Transkript

1 von Software systematisch oder agil? Prof. Dr.-Ing. Andreas Spillner Hochschule Bremen Testing Day Baden-Württemberg

2 Vorstellung meiner Person Studium der Informatik an der TU Berlin Praxis Migrations- und Entwicklungsprojekte, Softwareentwicklung Promotion Universität Bremen seit 1993 Professor an der Hochschule Bremen Fakultät Elektrotechnik & Informatik Lehre Softwaretechnik, Qualitätssicherung Programmierung Forschung Softwaretechnik, Validation und Verifikation von Software, Testmethoden, Prozessmodelle GI-TAV Gründung der Fachgruppe»Test, Analyse und Verifikation von Software«und deren langjähriger Leiter GI-Fellow Ernennung 2007 GTB German Testing Board Gründungsmitglied* Ehrenmitglied seit 2010 ASQF Arbeitskreis Software-Qualität und Fortbildung Mitglied im ASQF-Beirat Leiter FG-SW-Test Norddeutschland* * bis Ende

3 von Software Soll dazu beitragen, Fehler vor dem Einsatz der Software zu finden die Qualität der Software nachzuweisen Vertrauen in die Software zu schaffen Softwaretest meist ungeliebte Tätigkeit selten anerkannt kaum im Studium gelehrt in der Praxis hohe Bedeutung 30-50% der Gesamtkosten der Entwicklung 3

4 Computer Zeitung unter 100 IT-Managern zum Gelingen von DV-Projekten vom 10. April

5 Ziel des Tests Durch stichprobenhafte Programmläufe Nachweis der Erfüllung der festgelegten Anforderungen Aufdeckung von eventuellen Abweichungen und Fehlern Dabei mit möglichst wenig Aufwand möglichst viele Anforderungen überprüfen bzw. Fehler nachweisen Vorgehen kein»ad-hoc«-test Stresstest 5

6 Softwaretest in der Praxis Wissenschaftliche Leitung Förderer Unterstützer 6 2

7 Softwaretest in der Praxis Umfangreiche rollenspezifische bogen (110 Fragen) Projektleiter, Testmanager, QS-Beauftragte, Tester (110) Business Analyst, Entwickler, Betrieb & Support, Andere (63) Executive und mittleres Management (51) Ausfüllquote 1623 haben die begonnen (1779 aufgerufen) 810 haben die letzten Fragen beantwortet 1008 Projektleiter, Testmanager, Tester... (1092) Business Analyst, Entwickler,... (421) Executive und mittleres Management (266) 137 Einschätzung der Datenqualität gut bis sehr gut, allein durch die hohe Anzahl der Beteiligung hoher Ausbildungsgrad und Berufserfahrung hohe Nutzung der Freitextmöglichkeit ( ) 7

8 2011: Vorgehensmodelle Fragen zu den in der Praxis verwendeten Vorgehensmodellen 8

9 2011: Vorgehensmodelle Fragen zu den in der Praxis verwendeten Vorgehensmodellen 9

10 2011: Vorgehensmodelle Fragen zu den in der Praxis verwendeten Vorgehensmodellen 10

11 im Entwicklungsprozess - Allgemeines V-Modell Anforderungsdefinition Abnahmetest funktionaler Systemtest Systementwurf technischer Systementwurf Integrationstest Komponenten -Spezifikation Komponententest Konstruktionsphasen Teststufen Programmierung Testfälle basieren auf den entsprechenden Dokumenten 11

12 1997/2011: Prüf- und Testaktivitäten - wann? Wann werden Prüf- und Testaktivitäten durchgeführt? Wann wird damit angefangen? Gibt es Veränderungen in den letzten 15 Jahren? von 1997 KORREKTU ( ) ( ) 12

13 1997/2011: Prüf- und Testaktivitäten - wann? Wann werden Prüf- und Testaktivitäten durchgeführt? Wann wird damit angefangen? Gibt es Veränderungen in den letzten 15 Jahren? von ( ) ( )

14 ist keine späte Phase umfasst mehr als die Ausführung der Testfälle Vorbereitende Aktivitäten: Teststrategie ist festzulegen was soll wie intensiv mit welchen Methoden getestet werden Planung der Testaktivitäten wer soll was, wann und wie lange testen Testziele festlegen was soll erreicht bzw. durch Tests nachgewiesen werden Review der Testbasis Kontrolle der Ausgangsdokumente für den Test Testumgebung bereitstellen frühzeitig damit beginnen, um Verzögerungen zu vermeiden Testfälle spezifizieren (bzw. Testideen festlegen) helfen auch bei der Implementierung als weitere Informationsquelle Alles kann parallel zu den Entwicklungsaktivitäten erfolgen! 14

15 W-Modell Anforderungsdefinition Vorbereitung Abnahmetest Durchführung Abnahmetest debug funktionaler Systementwurf technischer Systementwurf Komponentenspezifikation Vorbereitung Systemtest Vorbereitung Integrationstest Vorbereitung Komponententest Programmierung Durchführung Integrationstest Durchführung Komponententest Durchführung Systemtest vor der Programmierung sind alle Testfälle spezifiziert und ca. 75% der Testaktivitäten abgeschlossen debug debug Änderung debug Review, PREviews, Dokumente Testfälle, Testrahmen test, debug, ändern, re-test Spillner, Roßner, Winter, Linz: Praxiswissen Softwaretest - Testmanagement 3. überarbeitete und erweiterte Auflage, dpunkt, 2011, Kapitel 3.4 W-Modell 18 15

16 2011: Testprozess? Gibt es für die Durchführung der Testaktivitäten einen festgelegten Prozess? 16

17 2011: Testprozess? Gibt es für die Durchführung der Testaktivitäten einen festgelegten Prozess? }ca. 70% 17

18 ISTQB - Testprozess Ist eng verzahnt mit der Softwareentwicklung Ist jedoch ein eigenständiger Prozess Beginn Es ist ein verfeinerter Ablaufplan für die Tests jeder Teststufe notwendig Die Entwicklungsaufgabe»Test«ist in Arbeitsabschnitte aufzuteilen: Testplanung und Steuerung Testanalyse und twurf Testrealisierung und Testdurchführung Bewertung und Bericht Abschluss der Testaktivitäten ISTQB - International Software Testing Qualifications Board Planung und Analyse und Entwurf Realisierung und Durchführung Bewertung und Bericht Abschluss Ende Steuerung ISTQB - Lehrplan Certified Tester - Foundation Level

19 Testprozess & W-Modell Steuerung Anforderungsdefinition funktionaler Systementwurf technischer Systementwurf Vorbereitung Abnahmetest Beginn Vorbereitung Systemtest Beginn Planung und Vorbereitung Integrationstest Beginn Planung und Planung und Analyse und Design Analyse und Design Analyse und Design Realisierung und Durchführung Steuerung Realisierung und Steuerung Durchführung Realisierung und Steuerung Durchführung Auswertung und Bericht Auswertung und Bericht Auswertung und Bericht Durchführung Systemtest Durchführung Integrationstest Abschluss Abschluss Abschluss Ende Durchführung Abnahmetest Ende Ende debug debug debug Komponentenspezifikation Vorbereitung Komponententest Beginn Planung und Analyse und Design Realisierung und Durchführung Durchführung Komponententest Auswertung und Bericht Abschluss Ende debug Programmierung Änderung

20 Kenntnisse über Testmethoden Welche Testmethoden sind Ihnen bekannt? Welche werden von Ihren Testern angewendet? Wissen sie, wann sie welche Methode sinnvoller Weise anwenden können? A Test Design Poster for Smarter Testing, Peter Zimmerer, EUROStar

21 Kenntnisse über Testmethoden 21

22 2011: Einsatz von Black-Box Testverfahren Welche twurfsverfahren sind in der Praxis im Einsatz? 22

23 2011: Einsatz von Black-Box Testverfahren Welche twurfsverfahren sind in der Praxis im Einsatz? 23

24 2011: Einsatz von White-Box Testverfahren Welche twurfsverfahren sind in der Praxis im Einsatz? 24

25 - Vor- & Nachteile Vorgehen, durch Einsatz des Testprozesses und durch Auswahl von geeigneten Testmethoden Kriterien können vorab festgelegt (und deren Erreichen kontrolliert) werden, wenn das als ausreichend anzusehen ist Testaktivitäten können frühzeitig beginnen und parallel bearbeitet werden Spezifikation der Testfälle komplettiert die Anforderungen und die weiteren Spezifikationen Ausführung der Testfälle erst bei vorhandenem Programm(teil) Änderungen der Anforderungen wirken sich auf die bereits spezifizierten Testfälle aus In der Regel werden mehr Testfälle spezifiziert als später ausgeführt 25

26 Agile, leichtgewichtige Prozesse Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ( ) 26

27 Was zeichnet agiles aus?» in agilen Projekten unterscheidet sich vom klassisches in erster Linie dadurch, dass dieselben Tests viel häufiger ausgeführt werden müssen. Schließlich wird das System immer wieder geändert (Refactoring) und viel häufiger ausgeliefert. Daher lohnt sich die Automatisierung der Tests in agilen Projekten viel früher als in klassischen Projekten. Aus dieser essenziellen Bedeutung des s in agilen Projekten hat sich eine spezielle Perspektive auf Tests entwickelt: In agilen Projekten werden Tests als ausführbare Spezifikationen verstanden. Folgerichtig werden Tests in agilen Projekten vor dem getesteten Code erstellt (Test First). Konsequenterweise werden die Product-Owner direkt in die Erstellung der Akzeptanztests einbezogen. Diese Akzeptanztests sind Bestandteil der fachlichen Anforderungen.« ( ) 27

28 TDD - Test Driven Development Agile Softwareentwicklungsmethode für sehr kurze Entwicklungszyklen: Add a test Run all tests and see if the new one fails Write some code Run the automted tests and see them succeed Refactor code Repeat Rot - Grün - Refaktorisierung - Zyklus ( ) ( ) 28

29 TDD Vorteile Im Mittelpunkt für den Entwickler stehen die Anforderungen, sie müssen verstanden sein, bevor programmiert wird Frühzeitiges findet Fehler frühzeitig im Entwicklungszyklus Kaum Redundanz durch Refaktorisierung Kein»unnötiger«Code Einschränkung:»Test-Driven Development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations.« ( ) 29

30 TDD - in Wikipedia»Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt. Die eigentliche Programmierung erfolgt in kleinen und wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile: 1. Schreibe einen Test für das erwünschte fehlerfreie Verhalten, für schon bekannte Fehlschläge oder für das nächste Bröckelchen Funktionalität, das neu implementiert werden soll. Diese Tests werden vom bestehenden Programmcode erst einmal nicht erfüllt bzw. es gibt diesen noch gar nicht. 2. Ändere/schreibe diesen mit möglichst wenig Aufwand, bis nach dem anschließend angestoßenen Testdurchlauf alle Tests bestanden werden. 3. Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Code- Duplizierung), abstrahiere wo nötig, richte ihn nach den verbindlichen Kodekonventionen aus etc. Natürlich wieder mit abschließendem. Ziel des Aufräumens ist es, den Code schlicht und verständlich zu machen. Diese drei Schritte werden so lange wiederholt, bis die inzwischen geschaffenen Tests alle bestanden werden und dem Entwickler keine sinnvollen weiteren mehr einfallen, die vielleicht noch scheitern könnten. Die so behandelte programmtechnische Einheit (Unit) wird dann als (vorerst) fertig angesehen.« ( ) 30

31 TDD Sichtweisen Design Methode:»Die Tests noch vor den Komponenten zu schreiben, die man eigentlich testen möchte, ist sehr markant für TDD. Dies wird als Test-First bezeichnet und darum ist TDD keine Test-, sondern eine Designstrategie. Denn wird der Test zuerst geschrieben, so wird die Schnittstelle der zu testenden Komponente bereits benutzt, bevor sie tatsächlich existiert. Der Entwickler bekommt frühestmöglich Feedback, ob das Design auch verwendbar sein wird.«die Testfälle sind eher Beispiele für die Nutzung der Schnittstelle, deshalb wird auch von Example Driven Development gesprochen ( ) 31

32 Testgetriebene Entwicklung Stellt das an den Anfang... aber allzu oft ist der»grüne Balken«das Testziel in Kombination mit systematischer Herleitung der Testfälle eine sinnvolle Vorgehensweise... aber auch nicht für alle Projekte gleich gut geeignet! 32

33 - Vor- & Nachteile hat an Bedeutung gewonnen! ist keine späte Phase! Durch die Testfallerstellung werden Schnittstellen festgelegt Testfälle ersetzten die Spezifikation Testfälle werden nicht systematisch hergeleitet nachvollziehbare Endekriterien sind nicht gegeben Ein mit TDD erstelltes System ist kein»getestetes«system! 33

34 2011: agile Vorgehensweisen Welche agilen Vorgehensweisen werden in der Praxis genutzt? 34

35 2011: agile Vorgehensweisen Welche agilen Vorgehensweisen werden in der Praxis genutzt? 35

36 2011: Verantwortlich für die QS? Wer ist im Unternehmen für die QS verantwortlich? 36

37 2011: Verantwortlich für die QS? Wer ist im Unternehmen für die QS verantwortlich? 37

38 2011: Kundenbeteiligung Sind die Kunden bei den agilen Vorgehensweisen mit»im Boot«? 38

39 2011: Kundenbeteiligung Sind die Kunden bei den agilen Vorgehensweisen mit»im Boot«? 39

40 2011: Agile Praktiken und QS Welche Praktiken der agilen Vorgehensweisen haben eine hohe Bedeutung im Hinblick auf die Qualitätssicherung? 40

41 2011: Agile Praktiken und QS Welche Praktiken der agilen Vorgehensweisen haben eine hohe Bedeutung im Hinblick auf die Qualitätssicherung? 41

42 2011: Testautomatisierung Wie hoch ist der Grad der Automatisierung auf den Teststufen? 42

43 2011: Testautomatisierung Wie hoch ist der Grad der Automatisierung auf den Teststufen? 43

44 2011: Qualität der entwickelten Software Produzieren agile Projekte bessere Qualität? 44

45 2011: Qualität der entwickelten Software Produzieren agile Projekte bessere Qualität? 45

46 2011: Weitere Informationen zur 46

47 Konkretes Vorgehen Iterativ (kleine Vs oder besser kleine Ws für jede Iteration) Testautomatisierung von Anfang an vorsehen Vorgehen mit systematischer Herleitung der Testfälle verknüpfen Entwickler für das motivieren ggf. schulen frühzeitige Klärung, wann ausreichend genug getestet ist Passendes Vorgehen zum jeweiligen Projekt There is no silver bullet! 47

48 von Software systematisch oder agil und Prof. Dr.-Ing. A. Spillner Hochschule Bremen Flughafenallee 10 D Bremen Ihre Fragen bitte Andreas.Spillner@hs-bremen.de