Performance Testing applied

A view years back a client's back office system failed and queued all of their web service requests to our system. When they had fixed the issue, their queue was about to get emptied. Too many submissions were executed all at the same time. As a result OUR system went down.When we fixed it on our side, our management excused about the downtime and made a proposal to our client to announce next time when they start with a massive load again. Since it wasn't really a massive load, our client didn't find that statement very funny and responded similar like the penguin in the cartoon.

Early Hotfixes

Where I work, hotfixes were things we dealt long before we started developing software. Their appearance was a little bit different, but they solved similar issues.

A beautiful exemplar of "ugly workarounds"  from the Sixties was presented to me just yesterday. I took a shot with my camera and I just couldn't resist posting it here...

Power Breakdown in Zurich

It can really be a hard day if you sit there and wait, and not even the coffee-maker is pluged to the emergency backup generator.

How developers see their code

The idea of this cartoon was born after a conversation with a developer who didn't intend to clarify whether a certain piece of code was working as expected.
 The developer stated: "by looking at the code, I know that it works".
Actually, he wasn't at fault, but it was kind of amusing for me to see how different developers think compared to software testers.

I don't believe in code-snippets that I see on a piece of paper or checked-into some source code management system. I want to see this thing run, fly and rock before I make a statement that I like what I have seen. Besides, it also reminded me to another developer statement I've accidentally witnessed many many years ago and I will never forget that phrase which was: "I haven't tested it, but the implementation looks great".

To be honest, I can't tell here whether the developer said that to himself to blow his own horn or whether he was talking to another developer to compliment on his work.

However, after all these years being involved in many testing projects and having developed software myself long time ago, I have always marveled developers' ability of innocent look at their code like they constructed a beauty, only to learn a little later from a critical thinker that either half of it is missing or not working as intended. When I was developing software my own, I was always uncertain whether I did the right thing and I asked the customer several times, if this is really how this thing should work. But that was 20 years ago and we didn't have any testers at that time who served as a protective barrier between development team and customer. The customer was coming to us - developers - every six weeks to tell us where we were wrong. We faced these customers directly. Maybe that made a difference.

Cross delivery

After the introduction of shorter release cycles, I noted a higher rate of bugs and features that had to be cross-delivered. Often this cross-delivery caused additional problems either because it happened on the wrong stream or it went forgotten. As a result old known bugs re-occurred in different streams.

I worked several hours on this cartoon and I prepared not less than 10 different drafts which I all abandoned because I was not happy with the characters I chose to represent the code pieces. l I finally decided to take that little triangle from Java. I kept a few of the drafts and decided to upload the last two of them so you can see how things develop.

Lineup of the ugly bugs

This is one of these wonderful moments where you get flooded by some nice creatures that can ruin your day or even the week.

Finding the right moment for your tests

There are these great moments in a testers's life when you realize that some of those great testing ideas tests should have been applied a little earlier.

Inspiration:

On February 21, 1990, commander Hans Lutz, carried out a system training on the Saab 340 aircraft type with a copilot onboard. The discussion turned to the procedure of remedying a landing gear retraction fault. The commander was of the opinion that on the ground, with the landing gear under load, the function of the retraction mechanism was interrupted. Contrary to the commander’s assumption, the hydraulic pumps began to work and the retraction process could not be interrupted. The aircraft impacted on the ground and was a total loss.

Source:
https://www.sust.admin.ch/inhalte/AV-berichte/1793_e.pdf (chapter 1.5.1.4.2)

Use the tools

If you have the tools, use them

The Debugger

...

Foreign Particles in the Code

There was this ugly bug which was sitting quite comfortable on this box until this chain of code went live and the release manager asked once more "why haven't you found this bug"?

Why is it always the testers who "fail" when a bug is going live and why is none ever asking the developers why they introduce bugs without asking the testers upfront for permission to ship  bugs?

High IQ cat

All of us had to play this weird online game which - we believe - should either measure our IQ, gather information on how we work or how we deal with pressure. None knew! We never received the results; no feedback. All we saw were points achieved without knowing what is good or bad. We did not even get any answers to bugs we reported while playing the game.

One of the team-mates made the game play with itself. No human interaction, simply doing nothing, no keyboard clicking or whatsoever and he disappeared into the cafeteria. That person achieved the most points of all.

What does it tell us? That game was either crap and with it of course all the results that were collected from the employees or there is something we just didn't know. We will never know.

Playing with Darts

...