tag:blogger.com,1999:blog-954576846660841512024-03-13T21:18:09.045-07:00TestautomationErfolgsfaktoren der Testautomatisierung was macht da Sinn? Wer das Thema Testautomatisierung ernst nimmt, wird am Erfolg gemessen aber wie immer liegt es an kleinen Dingen ...Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-95457684666084151.post-82700817898684709372013-10-20T02:29:00.004-07:002013-10-20T02:29:52.860-07:00Xebium<br />
<br />
<a href="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" style="color: purple; font-family: Calibri, sans-serif; font-size: 15px;"><span style="color: windowtext;">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</span></a><span style="color: #1f497d; font-family: Calibri, sans-serif; font-size: 15px;"> </span>Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0tag:blogger.com,1999:blog-95457684666084151.post-32410817103872385932012-01-03T14:52:00.000-08:002012-01-03T14:52:22.426-08:00Pragmatismus statt PerfektionNicht 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 ;-)Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0tag:blogger.com,1999:blog-95457684666084151.post-66589000868384767042012-01-01T04:03:00.000-08:002012-01-01T04:03:57.848-08:00Vollständige TestbarkeitIch 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. <br />
Wolfgang Strunk schreibt in seinem Blogg (http://www.softwarearchitektur.de/?tag=testautomatisierung)<br />
"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 <br />
<br />
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!<br />
<br />
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?<br />
<br />
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.<br />
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.<br />
Doch wie viel Aufwand muss und sollte man in die Vollständigkeit des Testautomaten setzen? ... <br />Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0tag:blogger.com,1999:blog-95457684666084151.post-56554317951273355072011-12-31T00:20:00.000-08:002011-12-31T00:20:04.831-08:00Essentielle Aufgabe der TestautomatisierungIch habe bislang in den letzten 3 Jahren 4 erfolgreiche Automatisierungsprojekte abgeschlossen. 3 Punkte waren in jedem Projekt wichtig:<br />
1. Klarheit-Verständnis<br />
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!<br />
2. Air-Bag- Transparenz<br />
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<br />
3. Zusammenarbeit-Entwicklungsprozess<br />
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<br />
<br />
Ich wünsche uns allen eine guten Start ins Jahr 2012!Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0tag:blogger.com,1999:blog-95457684666084151.post-88864602653507762011-12-29T15:08:00.000-08:002011-12-29T15:08:22.513-08:00Was sind kritische Frage zum Erfolgsset?Die Wahrheit liegt natürlich auch hier auf dem Platz!<br />
Man muss auch <b>Fehler finden</b>! Dazu brauchts <b>natürlich Tester</b>, die mit dem <b>Werkzeug umgehen</b> können! Und unter Tester verstehe ich Fachbereiche, Entwickler und Testingenieure. Hier gilt natürlich für Klarheit zu sorgen. Die <b>Fachlichkeit formalisieren</b> 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 <b>Konfigmanagementstrategie</b>. 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 <b>planbar</b> und <b>transparent</b> sein! <br />
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!Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0tag:blogger.com,1999:blog-95457684666084151.post-27380303934414505742011-12-29T14:56:00.000-08:002011-12-29T14:56:51.622-08:00Was 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 ;-)Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0tag:blogger.com,1999:blog-95457684666084151.post-10597535858577970612011-12-29T14:46:00.000-08:002011-12-29T14:46:07.023-08:00Erfolgs-Set für Open Source<div>Im Open Source Bereich gibt es ein konstruktives Set an Testtools:</div><div>Meiner Meinung nach, sollte man diese Tools jedoch gesteuert durch ein übergreifendes Konzept und möglichst vollständig anwenden</div><div>- <b>Hudson</b> Automatisierte Buildprozesse mit Subversion. </div><div>- <b>JUnit</b> Bietet Möglichkeiten zum Testen von Codemodulen. </div><div>- <b>Maven</b> ist ein standardisiertes "Makefile" und ermöglicht automatischen Download von Abhängigkeiten und bindet viele Testtools ein<br />
- <b>Fitnesse</b> Tests werden in einem Wiki oder Excel erstellt und ermöglichen die direkte Prüfung gegen die Anwendung.</div><div><div>- <b>Selenium</b> ein Web-Testing Framework </div></div><div> </div>Steffenhttp://www.blogger.com/profile/01546443802554577879noreply@blogger.com0