Fixing the Burndown Chart

Scrum Review Meeting

I have to admit that this is not really what was going on, but right after an awkward scrum review meeting, one of the team mates went to the hair-cutter and when he came back with lots of hair less on his upper part, this was kind of the feedback he earned from them, of course, not meant seriously.

Stand-Up meeting in Antarctica

A collection of the most important tasks discussed in the daily scrum-meetings in Antarctica

Cause-and-effect

Climate Warming

The cartoon's draft was drawn during a very long meeting where the subject had no direct relationship to this cartoon. But the more I think of it, the more it suits to the current technology transformation my teammates are going through.

In late 2022, I reworked the cartoon.

Agile movement in the wilderness

Bahhh ! or Moving to Islesbury

There were 2 different meeting rooms booked for the whole day.  If you were invited in the upper floor, you could stay. If you were invited to the lower floor, the HR boss asked you to sign a contract where you were promised a pay-off if you accept that they just fired you and if you also accept to stay in the company for another six months to perform a proper knowledge transfer to the new guys that are taking over our jobs.

What happened?

One year before this "shock", we understood messages like how much the offices of Davenport (town anonymized) is going to be strenghtend by the management.  At that time we had a lot of contractors and the management was worried because too much know-how was out-sourced, so they wanted to in-source again. They needed our help in seeking new talented people, not in Davenport, but in Islesbury (anonymized). Although this seemed kind of odd, we were supporting the idea to in-source. Several developers and testers interviewed a lot of Islesbury applicants and identified the most talented ones. Then they recommended those to HR and HR hired them. After the hiring process was complete, almost all engineers from Davenport got fired. Mere chance? Well, they still needed us for the next 3-6-months for the proper knowledge hand-over from Davenport to Islesbury. That's why we got this pay-off to make sure we all do a proper knowledge-transfer. Well, that’s a long story told short. Hardly anyone understood what was going on and why. Many talented, young and middle-aged engineers (who came from all over the world) were affected by this mass-layoff. These weren't rotten eggs but really skilled people. Officially, the reason submitted to us was “digital tranformation”. What a bummer! We are all software developers. Did they really expect us being unable to adapt?  However, most of us signed the contract and did a proper knowledge-transfer to Islesbury engineers. Others were disappointed and didn't give a tinker's damn about the pay-off. One didn't even show up in the office anymore.

Anyhow, at that time I was asking myself a lot about the meaning and success of such operation. Does the moving from Davenport to Islesbury really make any difference? They removed all the cows and hired much more sheeps. Did anyone do the math or was this just a personnel vendetta between managers that were at war with each other?

Function Talks

Visual Studio has this great built in feature that - on hovering over a method - immediately shows how often this method is used by other methods. When you develop code, you simply cannot ignore it and it actually makes you keep your code clean. If you see a method with zero references you just want to get rid of it immediately. Now that I use only the free version (Visual Studio Express) it is NOT included and I really miss it.

The truth about agile development and scrum

James Whittaker in his book "Exploratory Software Testing" (page 148) stated: "As testers, we must simply get the most work done that we can in the amount of time allotted to us".

Unfortunately, it's very popular to squeeze testing time when deadlines are near.

Years after I drew this cartoon, I worked in a project where we regularly had a burndown chart that looked liked the one below.
Hardly anything was delivered to testers until shortly before the sprint ended. We were thrown a huge bunch of completed tasks over the wall.

You might guess what happened next. Some testers felt the deadline pressure, too, hence probably didn't really accurate testing anymore and simply closed the tasks after a very quick and dirty smoke test (if at all); and all this just just to look great in front of the PM or to however one had to present the results. That's what obviously happened here. Dare those who work with testers who give a shit on deadlines and simply send back for rework all your half-baked features.

Rainy Spring Season

I have to apologize. This is the second cartoon in sequence without a direct relationship to my daily work as QA manager. Actually, there is a relationship, but it is not so obvious. I promise, the next cartoon will be again more focusing to IT again.

Unforeseen Consequences

Testing the Count Down

We had this announcement where the big boss stated that he would give us 90 days to change. OK, but change what? No satisfying answer was given to us when we asked what exactly they wanted us to change. So we continued doing our jobs as professional as always and I can tell you, we all worked very hard for the success of the company and to make our customers happy. Some of us even got a daily email with a reminder saying "80 days left", "79 days left"...etc. After the 90 days were expired, nothing happened. At least, we didn't notice anything and the emails had stopped.

I have no idea what was the original purpose of this announcement and the following up emails and I doubt that professinoal engineers can be impressed by such statements. Anyhow, this story inspired me for the cartoon, but if you are a software developer or test engineer then you probably draw a relation to a typical situation in software development.

A funny fact in programming is that arrays start at index 0 and not 1 for many popular programming languages (eg. C++,C#, Java, Perl, JavaScript) and the last position in the array is indexed as Array-length minus 1. This fact sometimes causes troubles and confusion and it isn't a rare scenario where developers introduce bugs because of that.

Consider the following piece of code which would cause the program to skip the first element of a list. It starts reading at position 1 (which is actually the second) instead of 0.

The correct code assigns variable i with value zero.

OK, so what? Blackbox testers usally don't look into the code of developers but you can see such patterns if you compare the total number of items in a list with the total number of found items stated in the header of a list. For example, you believe the label "100 items found", but when you count the items you see only 99.

For those who are curious why programmers start counting at 0 and not 1 I have the following explanation. In C, the name of an array is essentially a pointer (reference to a memory location), and so the expression sListElements[i] refers to a memory location i-elements away from the starting element. This means that the index is used as an offset. The first element of the array is exactly contained in the memory location that array sListElements refers (0 elements away), so it should be denoted as sListElements[0].

All Hands Meeting

Blah!

Management Decision Maker

As simple as LEGO

Bugs at the bar

I must admit, the cartoon is still in kind of a draft mode, since you still see the outline of the pencil.., I will correct that later.

After Lunch Atop a Skyscraper

The original picture showing construction workers sitting at lunch at the RCA building was created in September 29, 1932. Many parodies exist and here is yet another one, 84 years later, although I must add that this photo here was shot by myself from the Empire State Building in 1997. You can see its shadow. The birds were drawn at Sylvester 2015/2016 and the only "stolen" part here is the structural steel work and the cable on the right.
And what does this have to do with TESTING? Nothing, but these 11 testers mark my QA team spread all over the world, and although they are sitting high above ground, they've got wings and I hope they use them to overcome all following challenges and ups and downs we may face in this new year 2016.

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.

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 go through this weird online game which - we believe - should demonstrate how we work, maybe gather our IQ or how we deal with pressure. Actually none knows.... We never got the results, no feedback not even to bugs that we reported during the game...but what was the most funny moment  - the root cause for this cartoon - was someone not playing but simply letting the game play by itself. No human interaction, simply doing nothing, no keyboard clicking or whatsoever...just standby and this person got the same amount of points like others who were hacking into the keyboard like crazy....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

...

Empire State Building built with MINECRAFT

Sorry no cartoon today but something else impressive. The Empire State Buidling built by my son, block by block in MINECRAFT.

Watch video here:
Empire State Building built with MINECRAFT

Hard lessons in the Antarctic

...

Selfie Bugs

These bugs were inspired by Geri Müller

Snow white's Facebook profile

Fairy tales put into today's context

Compatibility Challenges

At the time I made this cartoon and when it was  published first in "Die neue Schulpraxis (02/2014), I didn't have any concrete scenarios in mind, but it happened just by accident that this cartoon now fits perfectly to an issue I faced recently where we deployed an updated version of the back-end software which was incompatible to very old client applications that communicate to our back-end system.

Robots Wedding

First published in
"Die neue Schulpraxis (2/2014)"

Arctic Tennis

First cartoon this year..

BTW, I was asked whether it was by purpose that I took a FEMALE penguin sitting on this tennis ball. Not really. The truth is, first I used a male penguin but then I suddenly questioned whether male penguins do hatch eggs. I wasn't quite sure but I still had in my mind that male and female are taking turns between each other. At that time it was already too late to verify (01:00 am) and I was too tired to do proper investigation. In the meantime I verified it. Both penguins are breeding the eggs. While one is hunting for food, the other takes over the breeding job.

Robot Breeding

published also at the "Testing Planet" here
ThnX Simon.

New App in town

This app introduced a completely new driving experience...

BTW, please excuse the grey shade in the last two cartoons. This is an ugly boring bug within Google's Blogger tool which introduces a grey background into all uploaded pictures even though whey are supposed to be clearly white.
There are some comments from other bloggers who suffer of the same problem. 

Waterproof