Category Archives: Testing

XLT 4.0 Developer Screencasts

The XLT Screencast PageWe just published four brand-new screencasts about XLT 4.0, its features, and how to work with them. This is our first attempt to use screencasts as a way of documenting our software. They do not replace the written documentation, of course, but they do provide a quick and easy way to become familiar with XLT.

You might be especially interested in the new Script Developer. Our main feature of XLT 4.0.

The script developer is our approach to write and execute scripts efficiently within Firefox. It is a tool to quickly automate web application, share scripts without the hassle of complicated installations, while maintaining full control over possible other ways to execute scripts. The script developer lays the foundation to run test within the browser, execute scripts during builds, create and run test-driven tests, and, if required, export scripts into Java to unleash the power of a modern programming language.

Enjoy the screencasts and of course feedback is always welcome.

Reasons for a Test Environment

People asked for a rough guide for running load tests against their live site and whether this is a good idea at all.

Well, let me first say that test environments exist for exactly that purpose. So if you already have something live, of course you used it before going live for load testing, and now you cannot run another test there… yes, you need a test environment. This is well spent money for several reasons:

  • Created data will not pollute your installation aka log entries, analytics data, orders in the database, created users, and so on.
  • You do not have to take your live site down for testing.
  • Problems during testing will not leave your live site down or take it down.
  • Your hosting company or IT department might charge for all test traffic against the live site as it would have been real traffic (revenue share, bandwidth utilization), so having your own testing realm makes expenses more predictable.
  • You can easily change code and retest when changes are necessary. You can profile, you can debug.
  • You do not risk problems with traffic going to live systems, such as payment due to configuration or testing errors. If you already had items from test orders piling up in your office, you know what I mean.

So, get yourself a test environment. Spend the money and enjoy the freedom to measure, debug, and tune.

P.S. Of course, there are situations, where you cannot replicate a live environment or you cannot find application problems in a test setup due to totally different timing behavior… Well, this indicates only that your live environment is already screwed.

Why Test Automation Costs Too Much

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!

Load Testing Web Applications – Do it on the DOM Level!

We published the article “Load Testing Web Applications – Do it on the DOM Level!” in the 10th issue of the testing magazine “Testing Experience“. This issue is all about performance testing. The article discusses our experience in web load testing on HTTP level versus HTML/DOM level.

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!

XLT 3.3.1 – Neue Kommentarfunktion

XLT-LogoJeder Tester hat sich bestimmt schon über den Aufwand geärgert, den man treiben muss, damit Testkonfigurationen, -ergebnisse und Änderungen an der Zielplattform für die spätere Testauswertung zur Verfügung stehen. Vor allem viele Änderungen während der Fehlersuche können das Testleben recht schwer machen. Weiss man dann wirklich immer noch, wie viele Server in diesem Moment liefen oder ob man die Cacheeinstellungen für diesen Testlauf angepasst hatte?

XLT hat hier bisher schon immer einen guten Job gemacht, denn es archiviert automatisch die Konfiguration zusammen mit dem Testreport und erlaubt so, jederzeit den Test zu wiederholen oder die Einstellungen nachzuprüfen. Aber Kommentare und Notizen zum Testzweck waren bisher nicht Teil der Daten.

Mit XLT 3.3.1 haben wir das geändert und eine Kommentarfunktion integriert, um schnell Testgedanken erfassen zu können und zusammen mit dem Test zu archivieren und natürlich auch in den Testergebnissen darzustellen.

Ab sofort können Kommentare und Informationen zur aktuellen Testkonfiguration hinzugefügt werden. Das ist vor allem wichtig, wenn man im Team arbeitet. Zusätzlich kann jeder Testlauf kommentiert werden. XLT fragt, ob man einen Kommentar hinzufügen möchte und speichert diesen gemeinsam mit dem Testergebnis ab. Alle Kommentare werden dann in den Testreport gerendert. So hat man sofort Ergebnisse und Notizen gemeinsam verfügbar.

Damit man seine Gedanken und Anmerkungen auch strukturieren kann, erlaubt XLT an dieser Stelle HTML als Eingabe. Besonders nützlich sind die Tags für Absätze (p), Listen (ul, li) und Hervorhebungen (em, strong).

Mehr dazu in den Release Notes von XLT 3.3.1.

Alle Verzeichnisse in einem Verzeichnis einpacken

Wer auf seiner Serverplatte (Linux) mal aufräumen möchte, der könnte den folgenden Shell-Schnipsel nützlich finden. Es TARt und komprimiert alle Verzeichnisse im ggw. Verzeichnis und räumt danach das gerade frisch eingepackte Verzeichnis weg. So lässt sich Platz sparen. Zum Beispiel weil man viele Testergebnisse herumliegen hat.

for i in `ls -d *` ; do tar cfz $i.tar.gz $i ; rm -rf $i; done

Getestet auf OpenSuse.

Andere Blogs rund ums Testen

Natürlich gibt es noch andere Blogs, die sich mit Testen und Qualitätssicherung beschäftigen. Einige davon möchte ich heute mit einem kurzen Kommentar vorstellen:

  • 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?

Was QA nicht machen soll

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.