Framework for Integrated Test (FIT)

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

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

3. 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 Teil 3 - IT: Pierre Feldbusch, NorCom • BeneFITs aus IT-Sicht • Zusammenfassung

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

5. 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  Risiken gefährden den Projekterfolg

6. Anforderungsentwicklung Ideale Anforderung: Beschreibung durch mathematische Funktionen Vorteile: • vollständig • eindeutig • konkret (leichter verständlich) • abstrakt (nützlich bei nicht-diskreten Wertebereichen) Quelle: Wikipedia.de  ABER: in vielen Einsatzbereichen zu aufwendig bzw. nicht möglich 

7. 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)  Wertetabelle:

8. Framework for Integrated Test (FIT)Idee und Konzeption  Wertetabellen aus den Anforderungen liefern ablauffähige Tests gegen den tatsächlichen Anwendungscode

9. Demonstration am Beispiel einer algorithmuszentrierten Komponente: Ganzzahl-Division FIT am BeispielExcel-Wertetabelle definieren

10. FIT am BeispielExcel-Wertetabelle definiert 

11. FIT am BeispielFixture-Klasse  Adapter zwischen Anforderungen und Anwendung

12. FIT am BeispielFixture-Klasse implementiert 

13. Anforderungen + Fixture = Test

14. 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?) • weniger Defects  in-Time, in-Budget • zufriedene Fachseite • erhöhte Chancen auf angemessene Architektur/Design • Reduktion der Projektrisiken

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

16. 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 … und Framework for Integrated Test (FIT)

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