Overheated server room

Knowing your dress size

This is one of a rare cartoon where its root is not from a software testing happening but rather developed from a colleague who missed his jacket. He sent an email to everyone asking who might have taken it.

It later turned out it was Jon (anonymized) who accidentally took it, but seemed not to realize this jacket was far too big for him. His height was quite a bit different from the owner’s.

The cartoon is a metaphor on what happens sometimes when companies start introducing UI test automation. You buy an expensive tool only to find out, what you want to automate is not supported or requires expensive add-ons. At the worst, one needs to hire experts to develop extensions, so the tool works well with the AUT (application-under-test). Of course, these extensions need maintenance and maintenance is seldom for free. I am not starting a debate about what's best, open source or off-the shelf. This answer can only be given in a context which we don't have here. But I strongly believe that it’s no bad practice to first start with a cheap or an open-source solution which fits your current "dress size" and which lets you experiment, and develop more specific ideas to learn better what you really need. Having enough time to explore helps you narrow down your requirements catalogue. You are growing with the experience you make and after a while you may end up realizing the current "jacket" no longer fits or needs some boosters. It may also be the right moment to restart the tool evaluation and look for a more suitable "jacket" that fits your new dress size, but at least you do this now with a more specific background - which is knowing your dress size.

Bug or Feature?

Alan Page in "How we test at Microsoft" wrote:

"One particular day, I spent several hours arguing with a developer about a "by design" bug. I thought his resolution was more a result of laziness and apathy than a sincere design decision. Eventually, I think we both gave up and decided to go home for the night.I was walking through the parking lot trying to remember where I parked (and couldn't help but laugh when I saw an old Volkswagen Beetle (or "Bug") parked in one of the stalls. The car was mostly navy blue but had a yellow cover on the engine with a vanity plate centered on it. The vanity plate read 'FEATURE'."

Source: How we test at Microsoft (Alan Page, Ken Johnston, Bj Rollison),2009, pg. 197 

Life as a Software Tester

I keep telling people that I have more talent to break things than to actually build things, since, whatever I touch breaks apart or results in another nice story that I can convert into a new cartoon published on this blog.
But honestly, I hope this is just a funny myth since I also built things successfully that are used by a large group of people worldwide. Maybe I just look at things a little bit differently. I love the speaches, articles and books of James Whittaker, Dorothy Graham, Johnathan Kohl and many many more; I am hungry to learn from them on a continuous basis and apply some of these techniques to my daily work with pleasure. Even at home I keep myself busy with software testing matters whenever the time allows me to. This is what the cartoon expresses here.

It all started more than 20 years ago with test automation, developing and running automated UI and B2B tests, using tools such as Rational Robot, SOAPUI, InCisif, WatiN, Selenium (and my team also used Ranorex), integrated in CI with Jenkins and I totally love home-brew solutions developed in C# like the recently newborn keyword driven test automation framework which is (at least for me) the next generation of another great Excel based test automation tool we used at an earlier company. Why C#? Sorry, - I am not a Microsoft advocate but MS Visual Studio is simply one of the best IDEs I have ever seen.

I also love tools like PerlClip, AllPairs, KDIFF3. I love to test through the side-door and last but not least...

I love to draw cartoons about software testing, my way of expressing weird experiences into something more exhilarant.

Live demo / no more slides

Video conference characters

Oh man, you cannot imagine how I loved to draw this cartoon, but I understand that probably none except the people involved in this video conference might actually find this funny.
I posted it anyway because I just learnt an interesting topic. It is really difficult to draw a character just per se...it actually needs an incident or a happening that everyone associates doubtless to that same person. So is the Kiwi which everyone associates to our always cheerful developer from NZ who - at Halloween - had a skeleton behind his armchair. Darth Vader got his nickname from the fact that we can hardly see him in the video conference because he is always sitting in a dark grey shaded room and usually keeps a straight face...and then in the very act they caught me while I was drawing on the board the first drafts for today's portraits.

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 helps you keep your code clean. If you see a method with zero references, you just want to get rid of it immediately.

 Automated tests in NUNIT are declared using the [Test] attribute and in other programming languages there are similar terms in use to mark a method as a test-method such as @Test, or similar.

 Anyhow, if a developer forgets to add the attribute, nothing bad happens. The compiler does not care about it. The developer may have invested a lot of time developing the test case and then simply forget about setting the attribute. What happens is, the code is never executed and therefore never fails.

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].