Of course, the next line is the only right place. A curly bracket is a hermit and does not like to be put next to any other character… 

What is your opinion?

Cartoon courtesy of Geek and Poke under CC-BY-ND-2.0

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache. … It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. …reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%.

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!

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.

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.

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

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.

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.