Follow by Email

Sonntag, 20. Oktober 2013

Xebium



http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht.html?tx_mwjournals_pi1%5Bpointer%5D=0&tx_mwjournals_pi1%5Bmode%5D=1&tx_mwjournals_pi1%5BshowUid%5D=7466 

Dienstag, 3. Januar 2012

Pragmatismus statt Perfektion

Nicht immer ist die perfekte Lösung erreichbar. Doch der automatisierte Modultest ist ein absolutes Minimum. Bei meinen Kunden der AZH stand das neu eingeführte Abrechnungssystem lange auf der Kippe. Erst der konsequente Ansatz des Entwicklungsleiters zumindest in der "Entwicklung" mit flechendeckenden Modultests zu stabilisieren, rettet das System. Gerade der MDA-Ansatz machte hier die Erzeugung einer automatisierten Initial-DB nicht leicht. Durch Kapazitätsverschiebungen gelang es "ausscheidende" Entwickler zumindest temporär des "Entwicklungswahnsinns" zur Version 1.0 zu entziehen und Lösungen zu schaffen. Mitunter muss man solchen Zufälle auch provozieren, um politischen Gegebenheiten entgegegenzuwirken ;-)

Sonntag, 1. Januar 2012

Vollständige Testbarkeit

Ich stellte mir einige Zeit die Frage nach vollständiger Testbarkeit von Softwarelösungen. In meiner Forschungszeit in der korrekten Softwareentwicklung habe ich gelernt, dass der Nachweis der Korrektheit eines Stückchen Software ein Vielfaches an Aufwand kostet, als die eigentliche Erstellung. In der Amerikanischen Raketenforschung hat man dazu in den achziger Jahren einige hundert Mathematiker beschäftigt, um die Korrektheit der Algorythmen formal nachzuweisen (Parnas, Box-Struktur-Methode). Die lässt sich in der freien Wirtschaft "normal" nicht abbilden aber der Wunsch beleibt jedoch und ist gerechtfertigt. Wie bei jedem anderen Handwerk.
Wolfgang Strunk schreibt in seinem Blogg (http://www.softwarearchitektur.de/?tag=testautomatisierung)
"In jedem Fall ist die Softwareentwicklung selbst ein kreativer Prozess, der individuelle Produkte hervorbringt, wie z.B. auch der Hausbau – selbst bei Fertighäusern – zu individuellen Resultaten führt. Daher ist eine gewisse Analogie zum Handwerk nicht von der Hand zu weisen."Warum

Vergleicht man das "Handwerk" der Softwareerstellung in heutigen Projekten mit der Vorgehensweise zum formalen Beweisen von Softwarebausteinen in den 80'er Jahren so wird mal leicht feststellen, dass die Idee der Mathematiker stets eine Zerlegung der Software in prüfbare oder besser beweisbare Module war. Diese Module entsprechen einer mathematischen Funktion. Kombiniert mal mehrere Module miteinander, so entstehen wieder Funktionen ... Vorausgesetzt man hat die Anforderungen formal beschrieben, kann man hier richtig Mathematik anwenden!

Warum in heutigen Vorgehensweisen nicht eben diese Idee nutzen? Dies bedingt jedoch von Anfang eine andere Vorgehensweise im Projekt. Angefangen der Anforderungebeschreibung müsste die Umsetzung, also  die Softwareentwicklung, nicht nur die normalerweise unspezifisch formulierten Anforderungen und Architekturvorgaben berücksichtigen, nein auch von Anfang an auf die Prüfbarkeit der einzelnen Module ausgerichtet sein. Wie soll man mit Klassen und Methoden eine verifizierbare Funktion abbilden?

 Mit Fitnesse (www.fitnesse.org) ist man dabei auf dem rechten Weg! Das Fixturekonzept ist nichts anderes als eine konkrete testbare Funktion eines oder mehrerer Programmmodule. Die erstellbaren Testfälle mit ihren Entscheidungstabellen bilden die Software also als ausführbare Funktionen ab. Die entsprechenden Testsuiten kombinieren diese Funktionen und prüfen Grenzwerte.
Das Framework hat meiner Meinung nach das Handwerk der Mathematiker als Programmverfikatoren abgebildet auf eine Vorgehensweise, die es Softwareentwicklern, Test-  und Fachexperten möglich macht eine hochtransparenten Aussage zur Qualität der Software zu treffen.
Doch wie viel Aufwand muss und sollte man in die Vollständigkeit des Testautomaten setzen? ... 

Samstag, 31. Dezember 2011

Essentielle Aufgabe der Testautomatisierung

Ich habe bislang in den letzten 3 Jahren 4 erfolgreiche Automatisierungsprojekte abgeschlossen. 3 Punkte waren in jedem Projekt wichtig:
1. Klarheit-Verständnis
Man kann keine Automatisierungsaufgabe mit unklaren Vorgaben lösen. Deshalb war immer die erste Aufgabe für Vollständigkeit und Klarheit in der Softwareentwicklung zu sorgen!
2. Air-Bag- Transparenz
Essentielle Triebkraft der Automatisierungsaufgabe war jeweils der Wunsch des Kunden oder PL's einen Air-Bag zu bekommen und möglichst vor Auslieferung einfach zu wissen wo das Projekt steht. Da beide Parteien in der Regel die Finanzierung übernehmen, ist Transparenz wohl aktuell die Hauptaufgabe
3. Zusammenarbeit-Entwicklungsprozess
Es gibt verschiedene Wege einen Testautomaten zu erstellen. Will man im Projekt jedoch Klarheit und Transparenz erreichen, so ist das eine Aufgabe von allen Projektbeteiligten deren Denken möglichst über das Projekteinführungsende hinaus gehen sollte. Wenn der Software-Code auch über das erste Release hinaus nicht als unveränderbares Artefakt angesehen wird, sondern jede Codezeile, jede Anforderungsbeschreibung, jedes Meeting und jede Dokumentation als Ort und Thema der Zusammenbetrachtet wird, um ein gemeinsames Ziel zu erreichen, dann ist die Testautomatisierung ein geeignetes Mittel der qualitativen Zusammenarbeit in Softwareprojekten

Ich wünsche uns allen eine guten Start ins Jahr 2012!

Donnerstag, 29. Dezember 2011

Was sind kritische Frage zum Erfolgsset?

Die Wahrheit liegt natürlich auch hier auf dem Platz!
Man muss auch Fehler finden! Dazu brauchts natürlich Tester, die mit dem Werkzeug umgehen können! Und unter Tester verstehe ich Fachbereiche, Entwickler und Testingenieure. Hier gilt natürlich für Klarheit zu sorgen. Die Fachlichkeit formalisieren und als Testfälle beschreiben ist gar nicht leicht. Gerade dafür brauchts die Testfixtures (also die Buchstaben zur Testsprache) zeitnah. Und dafür muss der PL sorgen. Hinzu kommt noch eine geeignete Konfigmanagementstrategie. Der verantwortliche Testmanager muss auch unbedingt bedient werden. Die sind typischer Weise ein Testmanagementtool gewöhnt. Eine solche "Konkurrenz" lenkt nur vom Thema Testen ab! Also unbedingt beim Betrieb von Fitnesse planbar und transparent sein!  
Wenns jetzt noch eine Idee zum Refaktoring der Fixtures und Testfälle gibt, dann hat man alle Karten in der Hand die Entwickler zur Erfolgreichen Umsetzung zu treiben. Also agiles Testen ist angesagt!

Was macht das Erfolgsset so erfolgreich?

Gerade Fitnesse (Fitnesse.org) ist im Erfolgsset ein echtes Pfund. Das kleine aber nicht einfach zu handhabende Framework ist nicht nur ein Tool mit Wiki, sondern vor allem regelt es die Zusammenarbeit im Projekt. Philosophisch gesprochen vielleicht das Einzige auf das es ankommt ;-). Es fordert ganz klar die Frage nach der Verantwortlichkeit zum Testen im Projekt. Wo überall die Schuld an Fehlern und die Verschleierung des Aufwands hin und her geschoben werden, findet man mit Fitnesse klare Antworten auf Vorgehensweise und Aufwand, wenn man das Framework bereits früh genug einsetzt. Fitnesse erst in der Endphase eines Projektes einzusetzen macht natürlich auch Sinn. Doch Achtung Manager, es werden fachliche Fragen aufkommen, die man vielleicht nicht hören mag ;-)

Erfolgs-Set für Open Source

Im Open Source Bereich gibt es ein konstruktives Set an Testtools:
Meiner Meinung nach, sollte man diese Tools jedoch gesteuert durch ein übergreifendes Konzept und möglichst vollständig anwenden
- Hudson Automatisierte Buildprozesse mit Subversion. 
- JUnit Bietet Möglichkeiten zum Testen von Codemodulen. 
- Maven ist ein standardisiertes "Makefile" und ermöglicht automatischen Download von Abhängigkeiten und bindet viele Testtools ein
Fitnesse Tests werden in einem Wiki oder Excel erstellt und ermöglichen die direkte Prüfung gegen die Anwendung.
- Selenium ein Web-Testing Framework