Category Archives: Interesting Reading

Data Science Day 2022

After a two-year break, on 18 May 2022, the 4th Data Science Day Jena took place. The Friedrich-Schiller University is hosting this mini-conference format annually.

Xceptance presented this year a closer look at the data that is collected and processed during load and performance testing. René Schwietzke, Managing Director of Xceptance, talked about the challenges to capture the right data as well as translate the collected data into meaningful results. 

A load test simulates millions of user interactions with a website and therefore is capturing huge amounts of data points. These have to be transformed into a few numbers to make the result of the test easy to communicate but still preserve important details. The talk started with typical business requirements and expectations of the target groups of a load test. It showed the data XLT captures and the dimensions which later drive the data reduction. A few example data series demonstrated the challenges behind the data reduction and what numbers are finally used to satisfy the requirements.

An example load test result illustrated the talk with real data. That example test run created about 17,500 data rows per second which contain about 293,000 data points. The entire test result consists of 3.2 billion data points. This massive data set is turned into a consumable report by XLT in less than six minutes. 

For everyone with an interest in data science, this presentation also offers ideas for research in regard to unsolved data challenges. There might be even some Master’s and Bachelor’s theses topics waiting for you. 

You can find a recording of the presentation below (courtesy of Thüringer Universitäts- und Landesbibliothek Jena).

This is the accompanying slide deck. It is a Reveal.js-based. You can navigate with the spacebar and the arrow keys.

Picture of the presentation

iJUG-Magazin Java aktuell – Performance Tests of Microservices

Load and performance testing is not trivial. Load and performance testing microservices is even more challenging. Our article “Performance Tests of Microservices” in the iJUG-Magazin Java aktuell talks about approach and challenges when designing and executing performance test for microservices. So get yourself the Java Aktuell or, if you just want to check out the article, use this link to the PDF and enjoy. The article is in German.

Performancetests von Microservices

Eine Softwarearchitektur, die aus kleinen und unabhängigen Teilen zusammengesetzt ist, ist einfacher zu erstellen und zu warten. Microservices sind dadurch zum dominierenden Thema in der modernen Softwareentwicklung geworden. Während die Komplexität auf der Entwicklungsseite sinkt, steigt sie in Bezug auf die Themen Architektur, Performance und Zuverlässigkeit. Dieser Artikel diskutiert die Anforderungen an die Performance und die Planung von Performancetests von Microservices.

Comments are very welcome.

Java Training Sessions

Today we are going to publish four of our Java training sessions so you can use the material and benefit from it.

Let’s get started with four direct links to extensive material that might help you to understand Java or code quality better or just help you to reflect on topics you already know.

  • The Java Memory Model: Why you have to know the JMM to understand Java and write stable, correct, and fast code.
  • Java Memory Management: Know more about the size of objects and how Java does garbage collection.
  • High Performance Java: All about the smart Java internals that turn your code into fast code and how you can leverage that knowledge.
  • High Quality Code: The anatomy of high quality code that supports longevity, cross-team usage, and correctness. This is not just about Java, this is about good code in general.

Show a little patience when loading the training, these are all large reveal.js based slide sets. Use the arrow keys or space to navigate. Because the slide sets are designed to be interactive sessions, in many cases, not the entire slide context is revealed at once but block by block.

We publish these training sessions because they are also based on openly shared material, it greatly helped us to advance and understand, as well of course advertise a little what Xceptance might be able to do for you.

We will release more of our material in the next weeks and month, so everybody can browse and learn. This won’t be limited to Java and also cover material about approaching load testing, how to come up with test cases, and more about the modern web and its quality and performance challenges. Of course there will be more Java material too. You can get a glimpse of it when you just follow this link and page through the slides: The Infinite Java Training. Please remember, not all material is complete yet.

If you like the material and you need an audio track aka a real presentation, please talk to us. If you see other training needs in the area of quality assurance, testing, and Java, please contact to us.

More to come.

Tutorial: Git – The Incomplete Introduction

Software Testing is part of software development. So you need a form of revision control for your source aka test code, and documents. You also need it to be able to review code, compare the history of code… or maybe simply to help others to master it.

We recently started our migration from Subversion to Git. Not because we have been unsatisfied with SVN, mostly because we want to use what our customers use. Additionally we want to profit from the different functionality Git offers, such as local commits and cheap branching.

But Git is different and just changing the tool does not change anything, it might even turns things worse. Because you cannot run Git like SVN. Well, you can, but that still requires you to know the basics of Git to understand what it will do to your work and how a typical workflow looks like. The commands are different too.

So we created this tutorial to get used to Git, understand, and learn it.
Continue reading Tutorial: Git – The Incomplete Introduction

Nice Reading: GitHub’s CSS Performance

GitHub CSS Performance, Title Slide

Another must read for the performance-aware programmer and tester. A nice slide deck about CSS performance issues at GitHub. Includes solutions as well.

A talk on some problems solved related to CSS Performance at GitHub. The talk was given at CSS Dev Conference in Honolulu, HI 2012. I recorded the presentation from my laptop and posted it here

Enjoy and keep in mind that performance matters.

Nice reading: CSS3 vs. CSS

Nice article about the advantages of CSS3 in terms of coding as well as download speed: CSS3 vs. CSS: A Speed Benchmark.

I believe in the power, speed and “update-ability” of CSS3. Not having to load background images as structural enhancements (such as PNGs for rounded corners and gradients) can save time in production (i.e. billable hours) and loading (i.e. page speed). At our company, we’ve happily been using CSS3 on client websites for over a year now, and I find that implementing many of these properties right now is the most sensible way to build websites.

Until today, all of that was based on an assumption: that I can produce a pixel-perfect Web page with CSS3 quicker than I can with older image-based CSS methods, and that the CSS3 page will load faster, with a smaller overall file size and fewer HTTP requests. As a single use case experiment, I decided to design and code a Web page and add visual enhancements twice: once with CSS3, and a second time using background images sliced directly from the PSD. I timed myself each round that I added the enhancements, and when finished, I used Pingdom to measure the loading times.


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!

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?

Die Gewöhnung an Abweichungen

Mike Mullane - Riding RocketsHeute hatte ich das Vergnügen, den Space Shuttle Astronauten Mike Mullane auf der STPCon 2009 kennenzulernen. Die STPCon ist eine Testkonferenz und Mike wurde eingeladen, um aus Sicht eines Astronauten Motivation zum Thema Testen zu versprühen. Man kann sich ja durchaus vorstellen, dass die NASA eventuell Sachen vorher ausprobiert, damit es dann erfolgreich fliegt.

Mike erzählte wunderbar, wie man als Astronaut lernen muss, die Toilette zu treffen, wie er zu NASA gekommen war, wie die Flugcomputer des Shuttles grob funktionieren usw. Aber der eigentliche Kern seiner Rede war Normalization of Deviance und es klang zunächst überhaupt nicht nach Testen.

Er erklärte uns verständlich, wie die Normalisierung von Abweichungen bzw. treffender die Gewöhnung an Abweichungen schlussendlich zu Katastrophen führt. Im Fall der NASA zu Unglücken, wie der Explosion des Challenger-Shuttles 1986.

Der Grund für das Unglück lag in einfachen Gummidichtungen (O-Ringe). Diese Ringe dichten die Feststoffraketen-Segmente ab. O-Ringe dürfen nicht porös werden und niemals mit Hitze in Kontakt kommen, denn das Innere der Rakete brennt aus und die Flamme darf nur nach unten und niemals zur Seite entweichen.

Der Hersteller entdeckte sehr zeitig, dass die Dichtungsringe mit Brandspuren von den Flügen zurückkehrten und alarmierte die NASA, da laut Vorschrift und Spezifikation niemals ein Ring mit Flammen in Kontakt kommen durfte. Da die NASA zu dieser Zeit unter extremen Druck stand, hat man das Problem verzögert, ignoriert und heruntergespielt. Immer mehr Flüge kamen mit immer mehr Schäden zurück, aber da bisher nichts passiert war, hielt man das Problem für hinnehmbar, obwohl die ursprüngliche Spezifikation und alle Warnungen des Herstellers andere Dinge erzählten.

Jeder Flug ohne offensichtliche Probleme, aber mit beschädigten Ringen, war quasi die Bestätigung der Abweichung. “Eigentlich haben wir doch kein Problem.” “Ist schon nicht so schlimm, ging doch bisher.” Am 28. Januar 1986 trat dann genau die Situation ein, die viele vorhergesagt hatten. Ein Techniker hatte sich nur um 73 Sekunden geirrt. Er hatte die Explosion am Boden erwartet.

Mit diesem drastischen Beispiel menschlicher Gewohnheit, hat er sehr schön einen unserer typischen Fehler vorgeführt, denn wir nehmen oft unter Druck Abkürzungen und gewöhnen uns dann daran, weil es ja gut ging. Jede erfolgreiche Abkürzung wird zur Bestätigung der Abkürzung, weil ja nichts passiert ist.

Für uns Tester heißt das übertragen, dass ein aus Zeitgründen ausgelassener Test wohl auch beim nächsten Mal ausgelassen wird bzw. man uns dazu “zwingt”, darauf zu verzichten, weil beim letzten Mal ja alles in Ordnung war.

Am Ende des Vortrages habe ich dann sein Buch Riding Rockets erworben, es widmen lassen und ihm die Hand geschüttelt, denn er hat Recht. Wir gewöhnen uns viel zu oft an unsere Ausnahmen und Abkürzungen… bis es eines Tages zu spät ist. In seinem Geschäft wird das dann eine Meldung in den Abendnachrichten. Glücklicherweise ist es in unserem Geschäft meist “nur” ein finanzieller Verlust.