I got a pretty nice link today. Check out that short article about the usual obstacles when trying or applying test automation: Why Test Automation Costs Too Much. Elisabeth covers the aspects of disconnected teams and the often practiced sharp distinction between programmers and testers pretty well.

Bottom line: the reason test automation costs so much is that it’s done in a silo far removed from the development effort.

Buffered from the consequences of design decisions that decrease testability, the developers continue to create software that’s nigh onto impossible to automate.

And isolated from the technical expertise of how the software was constructed, the test automation specialists are in a situation where they cannot help but be both inefficient and ineffective.

Enjoy reading!

Es gibt immer große Missverständnisse über die Rolle von QA/Test. Einige Leute wollen, dass QA das Produkt explizit freigibt und notfalls es aufhält, wenn es schlecht ist. Andere meinen, dass es besser ist, wenn QA einfach nur eine Empfehlung ausspricht.

Jon Bach hat heute auf der STPCon 2009 mit einem kurzen Satz schön zusammengefasst, welche Aufgabe QA hat. Ich teile seine Ansicht voll.

QA does not make quality. QA helps to make an informed decision about the quality.

QA/Test stellt den Zustand der Software/Hardware fest und informiert darüber. QA wird sich auf keinen Fall die Aufgabe auf den Tisch ziehen, zu richten. Das soll bitteschön der Auftraggeber, Programmmanager oder Projektmanager machen. Er bekommt den Bonus, er darf entscheiden. QA hilft nur dabei und zwar so gut, dass er eigentlich nicht anders kann, als der QA-Empfehlung zu folgen.

Für das Sun JDK deutet sich ein neuer Garbage Collector an, der ein anderes Herangehen hat und damit lange  Pausen noch deutlicher als der CMS vermeiden soll. Dem geneigten Leser sei dieser Artikel empfohlen: The Garbage First Collector!

Im JDK 6v14 könnten wir ihn vielleicht sehen. Ich bin schon ganz aufgeregt, da ich mittlerweile oft und viel mit GC-Internas hantiere… keine Wunder bei Lasttests gegen 120 CPUs mit Java drauf.

Viele Tester dürften diesen berühmten Ausspruch kennen:

Garbage in, Garbage out!

Er spricht mir manchmal aus der Seele. Es gibt immer wieder Momente, wo ich Software oder Projekte einfach nur in die Ecke werfen möchte und den Raum mit einem “Macht Euren Sche…. doch allein!” davonstürmend verlasse.

Warum eigentlich? Die Anwort ist ganz einfach.

Viele Softwareentwickler verlassen sich einfach blind darauf, dass es jemanden gibt, der nochmal drauf schaut. Da bekommt man Softwareruinen zum Testen vorgesetzt, die nicht mal die Qualität eines Prototypen haben. Die ersten Klicks, die ersten Blicke auf den Code sagen schon alles und fördern eine Handvoll offensichtliche Fehler zu Tage. Man muss sich nicht mal anstrengen.

Natürlich gibt man die Ruine mit freundlicher Mahnung zurück und bekommt später das Feature um die gefundenen Fehler behoben, dafür um weitere Fehler angereichert zurück. So geht das Spiele eine Weile, der Projektmanager stellt sich stur, der Termin zählt und zum Schluss hat dieses Feature eine Endqualität, die man eigentlich zur Testannahme erwartet hätte. Danach beginnt das Elend und der Endkunde fördert gnadenlos alles zu Tage und man darf sich die Vorwürfe des Projektmanagers gefallen lassen, warum man diese Fehler nicht gefunden hat.

In diesem Moment argumentiere ich gern mit folgendem Bild:

Wenn das Haus am Anfang nicht von allein stehen will, dann ändert die lange Mängelliste der Bauaufsicht nichts dran, dass zum Schluss das Haus unbewohnbar bleibt, obwohl es steht.

Damit endet mein momentaner Gefühlsausbruch auch schon. Schöne Woche noch.

Photo by Rossco (R & V Photographers) under CC-BY-2.0

Es gibt Zitate, die sind so erschreckend wahr, dass man sie einfach nur lieben muss und ihnen 100% Recht gibt. Das hier stammt von Bruce Schneier aus dem Crypto-Gram 1999/09/15 und gefunden habe ich es via  KeePass.

As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It’s true for cryptographic algorithms, security protocols, and security source code. For us, open source isn’t just a business model; it’s smart engineering practice.

Eine sehr wahre Weisheit von Andrew Tanenbaum:

As I did 20 years ago, I still fervently believe that the only way to make software secure, reliable, and fast is to make it small.