Monthly Archives: October 2008

Interesting Reading

Buchtipp: Lessons Learned in Software Testing

Nach langer Zeit habe ich mein Softwaretest-Lieblingsbuch mal wieder aus dem Schrank gezerrt: Lessons Learned in Software Testing. Übrigens eine Empfehlung und ein Geschenk von guten Freunden.

Für mich ist dieses Buch immer wieder eine Motivation mit QA und Testen weiterzumachen, weil es bestätigt und aufbaut. Es ist kein Wälzer mit theoretischen Lehren, sondern es enthält 293 Lektionen/Schnipsel mit wissenswerten Tipps und Ideen. Wer testet oder über das Testen Bescheid wissen muss, für den ist das Buch aus meiner Sicht Pflichtlektüre. Alle anderen Wälzer sind viel zu theoretisch und an der Praxis vorbei.

Lesson 11: You don’t assure quality by testing.

Testing, XLT

Implizite Safari-Tests

Es zeigt sich immer wieder, dass Webseiten, die sich schwer mit XLT automatisieren lassen und immer wieder mit Fehlern abbrechen, im Regelfall im Safari nicht laufen. Meist ist schlechtes HTML und fehlerhaftes Javascript Schuld. Praktisch diese impliziten Tests… aber manchmal auch nervig, da leider zuviele Leute den Safari, damit auch Google Chrome, ignorieren.

Das alles wäre gratis, wenn man einfach nur guten Code produzieren würde. Standards Baby, Standards!

Java, Software Development

Java und Virtuelle Server (VPS)

2 Comments

Wer sich einen virtuellen Server gemietet hat und sich quält, Java vernünftig zum Laufen zu bringen, dem sei dieser Artikel ans Herz gelegt: Java Web Hosting HowTo – vServer memory and Java heap size trouble.

Java Virtual Machines and Linux virtual Servers do not play well with each other all the time. Some tweaking and configuration will be necessary to get it working and optimize the use of the (memory) resources.

Die VPS / Virtuellen Server haben leider die Angewohnheit, den Speicher als zu gross zu melden. Sie melden den Gesamtspeicher des Hosts und nicht den Speicher des Virtuellen Servers. Deswegen schlägt Java gnadenlos zu, und versucht sich reinzuoptimieren. Die einzige Lösung ist die Limitierung des Speichers schon beim Start von Java mit -Xms und -Xmx, um die Selbstoptimierung von Java zu umgehen.

Java, Software Development

Softreferenzen gehen jederzeit

Softreferenzen (soft references) in Java sind eine tolle Sache, denn es lassen sich tolle Caches und Notfallszenarien damit bauen. Was kaum jemand weiß, dass Softreferenzen nicht nur im Falle von akuter Speicherknappheit freigegeben werden, sondern durchaus auch früher. Letzteres kann zu unerwarteten Nebenwirkungen führen, speziell mit Blick auf Caching.

Soft references are kept alive longer in the server virtual machine than in the client. The rate of clearing can be controlled with the command line option -XX:SoftRefLRUPolicyMSPerMB=, which specifies the number of milliseconds a soft reference will be kept alive (once it is no longer strongly reachable) for each megabyte of free space in the heap.

The default value is 1000 ms per megabyte, which means that a soft reference will survive (after the last strong reference to the object has been collected) for 1 second for each megabyte of free space in the heap. Note that this is an approximate figure since soft references are cleared only during garbage collection, which may occur sporadically.

Quelle: JDK 6 Garbage Collection Tuning Guide

Nachtrag: Erwähnenswert ist auch dieser Blogeintrag von Jeremy Manson.

Java, Software Development, Testing

Testedby

Heute habe ich einen interessanten Ansatz für eine Verbesserung von JUnit gefunden – TestedBy.

In a nutshell TestedBy aims to change the point of view regarding test classes and classes under test. What we would obtain is to put class under test (the most important classes of your projects) on the centre and link from there your test class and test method.

Ist einen Blick wert, da es scheinbar erstmal das Management der Tests verbessert.

Testing

Garbage in, Garbage out!

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

Bugs in the Wild, Testing Culture

Alle Macht den Monitoren

Ein Kollege hat mir gestern eine nette Geschichte erzählt und daran möchte ich jeden teilhaben lassen.

Man stelle sich vor, ein Arbeitsplatz mit einer besonderen Anwendersoftware, die man nicht überall einfach mal so installieren kann, weil noch Hardware dran hängt. Die Kollegen greifen bei Benutzung via Remote-Desktop zu. “Sag mal, der Wizard geht doch nicht mehr?”, “Was?”, “Na hier, ich drücke auf den Button, alles ist deaktiviert, aber der Dialog ist nicht da.”

“So ein Mist, ok wir suchen.”

Zwei Stunden später stellte jemand fest, dass der Arbeitsplatz zwei angeschlossene Monitore hat. Irgendwann hatte jemand den Dialog auf dem zweiten Monitor geparkt und dort blieb er auch. Jedes Mal, wenn er sich öffnete war er da, aber halt auf dem zweiten Desktop. Alle “entfernten” Kollegen sahen nur den ersten Desktop, der via Remote-Desktop zugänglich war.

Fazit: Zwei Stunden war der Arbeitsplatz wegen Fehlersuche lahmgelegt und dabei prügeln sich immer alle um seine Nutzzeit.

Misc, Software Development

Poetische Programmierer

Eben haben wir bei der Durchsicht der HtmlUnit-Änderungen im Subversion den folgenden Checkin-Kommentar gefunden.

– I have a dream, few tests to pass
– To help me cope with any class
– If you see the wonder of a fairy tale
– You can take next version even if you fail

– I believe in Java
– Something good in everything I see
– But sometimes hot as Lava
– When I know the time is right for me
– Ill cross the steam – I have a dream

Da scheint jemand seine Berufung nicht gehört zu haben ;)