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!

There is a free PDF version of the magazine that requires an online registration, where your e-mail address and country are required fields.

Enjoy reading!

Last month Google added Website speed to its site ranking algorithm: It’s Official: Google Now Counts Site Speed As A Ranking Factor… The rationale behind this move by Google is fairly straightforward:

Slow web sites lead to a poor user experience, and therefore should not appear at the top of the search list even if they contain relevant content.

This emphasizes once more the influence of performance on your daily business. A simple change to your site can now affect your entire page ranking and how users find your content. Continuous performance testing is now even more important than ever.

“…It appears that a considerable amount of browser sniffing scripts are not quite ready for this change to double digits, as they detect only the first digit of the user agent string: in such a scenario, Opera 10 is interpreted as Opera 1. This results in sites mistakenly identifying Opera 10 as an unsupported browser, thereby breaking server, as well as client-side scripts…”

Read more at Dev.Opera.

Cosmin Lehene wrote two excellent articles on Adobe’s experiences with HBase: Why we’re using HBase: Part 1 and Why we’re using HBase: Part 2. Adobe needed a generic, real-time, structured data storage and processing system that could handle any data volume, with access times under 50ms, with no downtime and no data loss. The article goes into great detail about their experiences with HBase and their evaluation process, providing a “well reasoned impartial use case from a commercial user”. It talks about failure handling, availability, write performance, read performance, random reads, sequential scans, and consistency.

(via High Scalability)

Jeremy ist bei Google angestellt und in viele JSR-Prozesse rund um das JDK involviert.

Google is now using page loading speed in their ranking algorithm. The engineering of some sites can make this a difficult problem to fix quickly, so webmasters should study the problem now with speed detection tools such as YSlow and Google Page Speed.

Das wäre nur konsequent von Google, da bereits die Webmaster-Tools in der Google-Administration die Seitengeschwindigkeit ausweisen. Zudem profitiert Google von schnellen Webseiten indirekt, da der Aufwand für die Indizierung sinkt bzw. die Updatezyklen kürzer sein können. Damit steigt auch die Aktualität von Suchergebnissen und das verbessert die Wettbewerbssituation für Google.

Wir freuen uns natürlich auch darüber, weil damit nicht zuletzt auch die Bedeutung von Last- und Performancetests steigt.

Google is what Google does with the software, and not the software itself.

Einfach mal lesen und sich seine eigene Meinung dazu bilden.

• DevelopSense von Michael Bolton (nicht der Sänger). Für Michael ist der Fakt wichtig, dass ein Tester viel wertvoller ist, als jede Automation. Das Hirn eines Testers ist sein Werkzeug. Er nennt es auch: Checking is not testing.
• James Bach vertritt eine ähnliche Meinung und verurteilt die blinden Bestrebungen, alles unkontrolliert zu automatisieren. Sein Kernbotschaft dreht sich um Exploratory Testing. Das intuitive, aber nicht zufällige Testen.
• Eric Jacobson legt sich nicht auf Gebiete fest, sondern kommentiert alles Querbeet.
• Nicht zu vergessen das Google Testing Blog. Hier berichten Google Tester aus ihrer täglichen Arbeit und den Herausforderungen von großer Software.

Wer kennt weitere empfehlenswerte Blogs?

Der JavaScript Beautifier ist eine schnelle und elegante Lösung, den Code wieder einigermaßen lesbar zu bekommen.

Bei der Erstellung und der Auswahl eines passenden Designs hat uns die Plattform 99Designs geholfen. Mit 99Designs lassen sich Design-Wettbewerbe schnell und effizient organisieren und man bekommt Vorschläge aus der ganzen Welt eingereicht. Wir waren sehr zufrieden mit dem Service und der Abwicklung. Unsere Designer war sehr freundlich, hilfsbereit und haben auch noch zusätzliche Ideen  umgesetzt, um uns die Entscheidung zu erleichtern. Nochmal vielen Dank an alle!

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.

Der Artikel stammt vom OWASP, der Authoriät im Sachen Internetsicherheit bzw. Informationen zur Sicherheit.

This article provides a simple positive model for preventing XSS using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack.

These rules apply to all the different varieties of XSS. Both reflected and stored XSS can be addressed by performing the appropriate escaping on the server-side. The use of an escaping/encoding library like the one in ESAPI is strongly recommended as there are many special cases. DOM Based XSS can be addressed by applying these rules on the client on untrusted data.

For a great cheatsheet on the attack vectors related to XSS, please refer to the excellent XSS Cheat Sheet by RSnake. More background on browser security and the various browsers can be found in the Browser Security Handbook.

Quelle: OWASP unter CC-BY-SA-3.0

Wer schon immer mal wissen wollte, ob seine Passwörter ansatzweise sicher sind, der sollte das The Password Meter ausprobieren. Das Ding ist wirklich pingelig. Was andere Prüfwerkzeuge als stark und superstark bewertet haben, das fällt bei The Password Meter unter: 0% – Vergiss es Dude!

Die Anwendung steht unter GPL und kann runtergeladen werden. Das gute Stück ist 100%-Javascript und die Eingaben werden nicht übertragen. Man sollte aber trotzdem nicht seine echten Passwörter eingeben, sondern ähnliche Muster. Also statt Helga78 tut es ein Katja87

Das Ganze ist kein Informatiker-Geek-Spiel sondern wirklich ernst. Viele 0815-Internetnutzer haben solche weichen Passwörter, dass es ein Wunder ist, dass sie noch nicht ausgeplündert wurden.

Wenn man über Webseiten-Performance spricht, dann denken die Meisten sofort an die Leistung des Servers bei der Auslieferung der Inhalte. Das ist im Prinzip auch nicht falsch, aber nur die halbe Wahrheit. Natürlich kann man eine Seite nicht schneller anzeigen, als sie ausgeliefert wird, so dass eine gute Leistung des Servers Grundvoraussetzung ist, aber es geht halt ohne grosse Anstrengungen langsamer.

Wie? Langsamer?

Moderne Webseiten bestehen aus vier Hauptkomponenten: Html, CSS, Javascript und statischen Inhalten, wie zum Beispiel Bildern und Flash. Die endgültige Webseite kommt nur im Browser zu Stande, wenn alle diese Einzelteile zusammengefügt wurden. Diese finale Schritt wird als Rendern bezeichnet.

Jede Einzelkomponente muss über das Netz geladen werden und die Komponenten werden in einer gewissen Reihenfolge geladen. So ist zum Beispiel immer zuerst die HTML-Hauptseite dran, dann Frames, dann CSS und Javascript aus dem Header, dann Bilder, dann anderer Content und irgendwo mittendrin wird noch das Javascript ausgeführt (denn Laden und Ausführen sind nicht das Gleiche). Um es kompliziert zu machen, macht es jeder Browser etwas anders.

Sollte ein Teil klemmen bzw. langsam sein, so können oder werden nachfolgende Teile nicht geladen und die Seite nicht bzw. unvollständig angezeigt. Oft fällt das beim Spiegel-Online, Welt-Online oder ähnlichen Angeboten auf, denn dort sieht man oft nur den Header und dann kommt einen Moment nichts… oder mehrere Momente nichts und endlich macht es Pling.

Da ich hier nicht alle Teile aus dem Yahoo-Performance-Guide kopieren möchte, wie man das Pling vermeiden kann und wie alles viel schneller geht, hier noch etwas erklärende Theorie für das Grundverständnis. Hier meine Favoriten und die bildliche Erklärung. Zuerst sei noch ein Missverständnis erklärt.

Meine Kunden haben doch Breitband, wo ist das Problem?

Breitband ist schön, Breitband ist toll, aber ein LKW mit Ladung ist auf einer 10-spurigen Autobahn nur unwesentlich schneller als auf den traditionellen zwei Spuren. Warum? Wenn ich Ware nach von A nach B bringe, dann muss ich den LKW be- und entladen, sowie der LKW muss auf die Autobahn auf- und abfahren. Egal wie breit die Autobahn dazwischen ist, diese Grundschritte sind immer dabei und immer gleich schnell. Eventuell haben wir nur weniger Stau unterwegs bzw. ich kann vier LKWs schicken, statt einem… sofern ich etwas zu transportieren habe und sich die LKWs nicht am Verladezentrum stauen.

Genauso verhält es sich mit Anfragen an einen Webserver. Das Datenpaket wird gepackt, versendet und ausgepackt, danach beantwortet, die Anfrage eingepackt, versandt und wieder ausgepackt. Nur die beiden Versandschritte gehen schneller mit einer dicken Leitung, der Rest bleibt.

Und wo ist nun das Problem?

Ja, ich habe es immer noch nicht richtig verraten, aber das Problem der meisten Webseiten ist, dass sie aus vielen vielen Einzelteilen zusammengesetzt werden und je mehr Teile es sind und je mehr Teile von unterschiedlichen Servern stammen, desto langsamer wird die Sache.

Das führt zum lustigen Effekt, dass das Laden von 5 Bildern a 50kB schneller geht, als das Laden von 10 Bildern a 15kB, obwohl die Gesamtgrösse der 10 Bilder deutlich geringer ist. Leider führen 10 Bilder zum Zweifachen Overhead im HTTP-Protokoll, in der DNS-Auflösung, in der Bestimmung der Serverantwort und und und.

Regel Nummer 1 heisst deswegen – Weniger HTTP-Anfragen

Diese Regel ist die absolut goldene Regel und lässt sich durch das Zusammenlegen von Einzel-CSS in ein CSS-File erreichen, durch das Zusammenführen von Javascript-Dateien und statt den Seiten-Header in 8 Bilder zu zerlegen, schickt man lieber nur 2 Bilder.

Man darf dabei auch nicht aus den Augen verlieren, dass diese Inhalte auch gecacht werden sollten, damit der Browser beim Weiterklicken nicht nochmal alles von vorn alles laden muss. Hier ist also zwischen Zerlegung, Grösse, und Wiederverwendung abzuwägen.

Regel 8 – Javascript und CSS gehören in Einzeldateien

Man sollte niemals CSS und Javascript in grossen Mengen in das HTML einbetten. Dieser Teile gehören extern und so aufbereitet, dass sie wiederverwendbar sind. Das macht die Pflege einfacher und die eigentlichen HTML-Seiten kleiner.

Regel 19 – Die Anzahl der DOM-Elemente reduzieren

Was der Browser nicht lesen muss, dass kostet keine Zeit und keinen Speicher. Jedes HTML-Element und vor allem jede Zeile Javascript-Code muss interpretiert und verwaltet werden. Damit ist eigentlich schon einleuchtend, dass der HTML-Code sauber und einfach strukturiert sein sollte.

Als Beispiel lässt sich bei

<div class="link"><span><a href="http://...">Linktext</a></span></div>

locker das span einsparen, denn a ist bereits ein Inline-Element und span fügt hier keine Struktur hinzu. Das ist aus der Praxis, das habe ich mir nicht gerade ausgedacht.

So, dass war eigentlich schon recht viel für den Anfang und deswegen gibt es demnächst mehr zu den anderen Tipps von Yahoo. Wer es eilig hat, der kann auch direkt nachlesen: Best Practices for Speeding Up Your Web Site.

Photo by 96dpi under CC-BY-2.0