Flux 140: Visuelle Tests automatisieren

Flux 140: Visuelle Tests automatisieren
Je größer eine Webseite, desto qualvoller werden manuelle Tests. Florian Sesser hat sich lange genug darüber geärgert und dann ein Tool programmiert, das vielen Leuten sehr, sehr viel Arbeit sparen kann. Auf der DWX in Nürnberg stellt er es gemeinsam mit der Quality Assurance Managerin und ehemaligen IT-Agentin Karo Stoltzenburg vor. Ein Gespräch über Flux 140. „Öde Jobs automatisieren“ heißt deine Präsentation auf der DWX – was ist so schlimm am Testen? [Mehr]

Smart versus Clever — Denkanstöße aus der Welt der IT:Agenten

Smart versus Clever — Denkanstöße aus der Welt der IT:Agenten
Obwohl die Begriffe “Smart” und “Clever” im (britischen) Englisch fast synonym sind, gelten sie manchen Programmierern als Antipoden in der Welt der Begriffe: Be smart, not clever! — Höchste Zeit das Thema bei den IT:Agenten, den *Smart Internet Experts, in einer gemütlichen Freitagsrunde bei Keksen und einer Mate unter die Lupe zu nehmen. Hier berichtet Thomas Fuhrmann, was er aus dieser Diskussion mitgenommen hat.* Everyone knows that debugging is twice as hard as writing a program in the first place. [Mehr]

Auch ein geschenkter Gaul muss mal zum Zahnarzt

Auch ein geschenkter Gaul muss mal zum Zahnarzt
In lockerer Folge erzähle ich hier ein paar Geschichten zur so genannten technischen Schuld, den verborgenen Kosten schlampig gemachter Software. In Anlehnung an einen aktuellen Bestseller behaupte ich dabei frech, Beispiele aus 5000 Jahren Menschheitsgeschichte abdecken zu können. Wie kocht ein Mathematiker Tee? Er räumt zunächst alle Utensilien auf, um dann von einem bekannten Problem ausgehen zu können. Wie kocht ein Programmierer Kaffee? Er nimmt sein Auto, um mit dem Kühlwasser den Kaffee zu brühen. [Mehr]

Technische Schuld — Die ersten 5000 Jahre

Technische Schuld — Die ersten 5000 Jahre
Et dimitte nobis debita nostra. — Matthäus 6, 9 – 13 Der Markt verzeiht keine Fehler. — Leitspruch des Marketings Software-Entwicklung ist üblicherweise aufwendig und kompliziert: Weder wissen die Kunden, was sie eigentlich wünschen; noch wissen die Entwickler, wie sie ein gegebenes Problem (am besten) lösen sollten. So bewegt man sich zwangsläufig im Zick-Zack, baut immer wieder um und häuft mit der Zeit eine Menge Unsinn an. Zeitdruck und die eigene Faulheit tun ihr Übriges: Der ‘eben schnell’ geschriebene Code bleibt – und bleibt – und bleibt… [Mehr]