Framework for Integrated Test (FIT) Customer Information Day, Norcom Frankfurt, 24.05.2007 Pierre Feldbusch, NorCom

Über mich Pierre Feldbusch Schwerpunkte Senior Consultant, NorCom Fon +49 (0)69-58996-0 pierre.feldbusch@norcom.de Schwerpunkte Java Enterprise Entwicklung Anforderungsentwicklung Testautomatisierung 0,5min 24.05.07

Agenda der nächsten 45 Minuten Teil 1 - IT: Pierre Feldbusch, NorCom Motivation Ideen und Konzepte ein einfaches Beispiel Teil 2 - Fachseite: Bernd Dörschler, Dresdner Bank Erfahrungen über den FIT-Einsatz in einem großen Projekt 1 min – 1,5 min Wichtige Verständnisfragen bitte gleich stellen, Ergänzungsfragen bitte auf die Diskussion verschieben Teil 3 - IT: Pierre Feldbusch, NorCom BeneFITs aus IT-Sicht Zusammenfassung 24.05.07

Anforderungsentwicklung ZIEL  IT versteht die Anforderungen Fachliche Zusammenhänge darstellen (Basis für IT) Beschreibung konkreter fachlicher Anforderungen STANDARD-TECHNIKEN: Prosa-Text  für Grobstruktur und Standardfälle UML (Functional Design)  Detaillierung 2 min – 3,5 min Obwohl das Wort “Test” im Namen des Frameworks vorkommt, lege ich den Schwerpunkt auf die Anforderungsentwicklung, weil das m. E. der Haupteinsatzbereich ist. Oberstes Ziel: IT versteht die Anforderungen Ziel ist ein Modell-Transfer von der Fachseite zur IT-Seite – die IT muß das Geschäftsmodell verstehen. Deshalb muß man die fachlichen Zusammenhänge zunächst darstellen, um eine Basis für das Verständnis der fachlichen Anforderungen zu schaffen. Vorteil Vision aufzeigen: Bei gleichwertigen Designalternativen kann eine Vision den entscheidenden Impuls geben (ohne Zusatzkosten zu verursachen) 24.05.07

Anforderungsentwicklung HAUPTPROBLEME: Hoher Abstraktionsgrad Mißverständnisse durch Sprache Unvollständigkeit implizites Wissen Grenzwerte/Ausnahmefälle KONSEQUENZEN: Fachliche Zusammenhänge unklar bzw. falsch verstanden  kurzfristig: viele Defects  mittelfristig: unangemessenes Design  langfristig: unangemessene Architektur 3 min – 6,5 min Formale Spezifikationen bergen Risiko der Verklausulierung durch einen hohen Abstraktionsgrad – d. h. alles korrekt beschrieben, aber niemand versteht es (weil das Big-Picture fehlt) Unterschiedlicher Background (Fachseite vs. IT-Seite) i. a. prallen zwei Welten aufeinander Unterschiedliche Sprache und Sprachverständnis Glossar hilft aber Gefahr besteht weiter Implizites Wissen wird weggelassen Problemfälle (Ausnahmefälle, Grenzwertbetrachtungen) werden in Fachkonzepten gern mal weggelassen, weil sie viel Zeit/Aufwand kosten und auch unangenehm sind (ähnlich wie Exception-Handling in SE-Projekten) Falsch verstanden … oftmals ist einem gar nicht bewußt, daß man etwas falsch versteht – man denkt, man hätte es verstanden Schlimmer als nicht-verstehen  Risiken gefährden den Projekterfolg 24.05.07

Anforderungsentwicklung Ideale Anforderung: Beschreibung durch mathematische Funktionen Vorteile: vollständig eindeutig konkret (leichter verständlich) abstrakt (nützlich bei nicht- diskreten Wertebereichen) 2 min – 8,5 min Wie sieht eine ideale Anforderung aus? eine Variante ist eine mathematische Beschreibung wie hier in Form einer Funktion Vollständig und eindeutig: für jeden Wert im Wertebereich kann ein genau ein Bildpunkt angegeben werden Konkret: man kann Beispielwerte berechnen Abstrakt: allgemeine Berechnungsvorschrift für den Bildpunkt – man kann für jeden Wert noch so ausgefallenen Wert aus dem Wertebereich den Bildpunkt berechnen ABER: diese Idealvorstellung trifft man in Praxis fast nie an Stattdessen müssen wir die Realität akzeptieren und Auswege aus diesem Dilemma finden Suche nach pragmatische Lösungen mit optimalem Kosten-/Nutzen- Verhältnis FIT ist eine dieser pragmatischen Lösungen vorstellen (es gibt noch viele, viele andere – Entscheidungstabellen, Prototypen, …) Quelle: Wikipedia.de  ABER: in vielen Einsatzbereichen zu aufwendig bzw. nicht möglich  24.05.07

Anforderungsentwicklung  pragmatische Anforderung: Wertetabelle Fachliches (mentales) Modell: Vorteile: immer einsetzbar eindeutig konkret entspricht menschl. Lernverhalten Quelle: Wikipedia.de Nachteile: unvollständig bei nicht-diskreten Wertebereichen  Äquivalenzklassenbildung Fehlinterpretationen sind möglich (Wertetabelle impliziert nicht Graph) 2,5 min – 11 min Es fällt uns vielleicht schwer, diese Kurve ad-hoc aufzuzeichnen oder sogar eine Berechnungsvorschrift anzugeben, ABER: wir können vermutlich für jeden x-Wert den entsprechenden y-Wert angeben Dadurch entsteht ein weniger formales Modell, aber ein praktikables – gemeinsam mit Prosa-Beschreibungen und UML-Diagrammen kann es viele Probleme beseitigen Bis jetzt nix wirklich neues, DENN: Zuhörer haben sicherlich schon desöfteren Beispiele zur Konkretisierung der Anforderungen eingesetzt ABER … jetzt werden diese Beispiele zu konkreten ablauffähigen Testfällen – und das fast ohne Zusatzaufwand   Wertetabelle: 24.05.07

Framework for Integrated Test (FIT) Idee und Konzeption  Wertetabellen aus den Anforderungen liefern ablauffähige Tests gegen den tatsächlichen Anwendungscode 3 min – 14 min FIT ist ein javabasiertes Open-Source-Framework 2 Aspekte: Anforderungsaspekt Testaspekt 24.05.07

FIT am Beispiel Excel-Wertetabelle definieren Demonstration am Beispiel einer algorithmuszentrierten Komponente: Ganzzahl-Division 2 min – 16 min Aufbau: Erste Zeile: technisch – später mehr Zweite Zeile: Benennung ergebnistreibender Parameter (Inputwerte) Benennung zu berechnender Werte (Outputwerte) Ab dritter Zeile: Beispieldaten Im besten Fall: Arbeiten Fach- und IT-Seite gemeinsam an der Wertetabelle, dann kann sich hieraus fruchtbarer Dialog hinsichtlich des Modellaustauschs ergeben der auch wesentlich effizienter als die One-way-Kommunikation über Spezifikationen oder eMails sind 24.05.07

FIT am Beispiel Excel-Wertetabelle definiert  0,5 min – 16,5 min 24.05.07

FIT am Beispiel Fixture-Klasse  Adapter zwischen Anforderungen und Anwendung 2 min – 18,5 min Hier kommt das FIT-Framework ins Spiel Abgeleitet von ColumnFixture ACHTUNG: es gibt noch andere Fixture-Klassen für andere Einsatzgebiete (z. B. Workflowkomponenten) Klassenname wurde im Excel-Sheet erwähnt Fixture-Klasse ist eine Java-Applikation (main-Methode) Enthält HTML-Testdaten Erzeugt HTML-Testergebnisse Spaltennamen der ergebnistreibenden Parameter sind public-Member (automatische Typkonvertierung) Nach setzen aller Inputwerte wird execute-Methode aufgerufen – hier Instanziierung des CalculationService (ich verwende zu Demonstrationszwecken einen CalculationService, der semantische Fehler und Laufzeitfehler erzeugt) ACHTUNG: ich habe hier absichtlich eine fehlerhafte Implementierung des „calculationService“ eingebaut – zur Veranschaulichung von Programmierfehlern 24.05.07

FIT am Beispiel Fixture-Klasse implementiert  0,5 min – 19 min 24.05.07

Anforderungen + Fixture = Test 2 min – 21 min Zu sehen ist Ergebnis der Fixture-Klasse Grün: Erwartungen entsprechen dem Ergebnis  Rot: Erwartungen entsprechen dem Ergebnis  - erwartetes und tatsächliches Ergebnis werden ausgegeben Entweder ist der Code falsch Oder die Erwartungen sind falsch (soll alles schon vorgekommen sein) Gelb: Laufzeitfehler während der Bearbeitung 24.05.07

BeneFITs – Probleme gelöst? Anforderungen werden klarer, Transfer wird erleichtert insbesondere bei gemeinsamer Erarbeitung der Wertetabelle Mißverständnissen wird vorgebeugt Abgleich des mentalen Modells gegen die Beispiele (Quercheck) Vollständigkeit – positive Auswirkungen: ergebnistreibende Parameter werden explizit dargestellt Berücksichtigung des kompletten Wertebereichs ergebnistreibender Parameter (Grenzwerte, Ausnahmefälle, was soll geschehen, wenn ein Wert undefiniert ist?) 3 min – 24 min weniger Defects  in-Time, in-Budget zufriedene Fachseite erhöhte Chancen auf angemessene Architektur/Design Reduktion der Projektrisiken 24.05.07

Weitere BeneFITs optimales Kosten-/Nutzen-Verhältnis minimale Kosten (Overhead: Fixture-Klasse) großer Nutzen sofort einsetzbar Automatisierte Akzeptanztests  sichere Refactorings Zusammenarbeit Fachseite/IT-Seite  Teambildung 2 min – 26 min Weitere Vorteile: Unterstützung des Domain-Driven-Designs Teststatistik Motiviert Status Junit-Test nutzbar 24.05.07

Zusammenfassung Semantik (u. a. Anforderungen) läßt sich nur mit unverhältnismäßig großem Aufwand eindeutig und vollständig beschreiben  Ziel: Lücken entdecken  Methode: Semantik aus verschiedenen Blickwinkeln betrachten: Prosa UML Prototypen Entscheidungstabellen 1 min – 27 min … und Framework for Integrated Test (FIT) 24.05.07

Quellen Ward Cunningham: http://fit.c2.com Frank Westphal: http://www.frankwestphal.de/TestgetriebeneEntwicklungmitJUnit undFIT.html JavaSPEKTRUM Artikelserie von Mario Gleichmann und Pierre Feldbusch, NorCom Januar 2007: FIT für Akzeptanztests März 2007: Automatisierte Akzeptanztests mit FIT 24.05.07