Category Archives: Testing

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!

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.

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

Korrekte Telefonnummern sind nicht falsch

Ich finde es immer wieder sehr nervig, wenn Programmierer einfach nicht mit Telefonnummern und ihren korrekten Ausprägungen umgehen können. +491727900000 ist nun mal eine 100% korrekte Nummer, aber die meisten Internetläden nehmen sowas nicht an und nerven mit Korrekturaufforderungen.

Bitte klicken Sie auf zurück und geben Sie eine korrekte Telefonnummer ohne Sonderzeichen ein.

Die Nullen sind von mir fürs Posting eingesetzt. Soll mich ja nicht jeder gleich anrufen.

Nach dem Lasttest

Ein Blick in die Lasttest-Mailbox

Nach vielen Lasttests in den letzten Tagen habe ich mal in meine Spezialmailbox geschaut und war ja etwas überrascht, dass es doch schon so viele Emails waren, die in der Zeit eingetrudelt sind. Man stelle sich mal vor, das wäre alles als auf dem Server hängen geblieben bzw. mit Beschwerde an den Admin gegangen.

Wobei ein Test mit Unzustellbarkeit auch ein schönes Testszenario ist…