The Template

Recently in the museum.

Doozy! Only two bugs left.

That's what I thought, until we got the next version...

As James Whittaker wrote in “Exploratory Software Testing”, bugs tend to congregate for a variety of reasons such as complexity of the code, skill of the assigned developer, number of bugs in the past, etc. To make it short; where you see one bug there are likely more near around. You just need to look for them.

Technical Debt not close-to-balance

I think it is normal in a project to accumulate technical debt somehow. You may have tough deadlines or other reasons to tend get things done more quickly than usual, probably with the mindset of getting it right later.

Other reasons for (quick) workarounds are new awareness (more experience) of how things work better under certain circumstances. The old approach was good for one particular problem, but not good enough for a general solution.

An increasing number of developers working on the same project may force the architect to enforce new coding guidelines or best practices for typical software development problems.

The use of embedded third party software may also trigger changes on your side when updates are delivered.

Technical debt should be avoided as much as possible and yes, there are scenarios where you are simply forced to live with technical debt. But, one should always be aware that, often, the time to improve old code won't be availble. Even if there will be such time, think about the risk of removing technical debt. Someone who works under pressure not only tends to seed ugly workarounds, but he is likely also adding sloppy unit tests (if he adds any at all). If that's the case, removing technical debts with refactored code adds new risks breaking functionality you won't know about until the customer reports them.

Banksy was here

Sotheby's in London has auctioned off a framed version of Banksy's iconographic subject "Girl With Balloon" for over 1 million pounds.When the final bid was made, the big surprise came. Suddenly the screen moved down and the picture was destroyed by a shredder built into the picture frame [nyt]. Right after the surprise, the anonymous artist had published a video detailing how he installed a shredder into the frame [ban].

The disturbing part of this story is that this picture has probably gained even more fame through this action and thus very likely becomes more coveted although shred in pieces; volitional or not, Sotheby's to be in the known or not, the buyer well-informed or not....who knows.

Sources:
[nyt]
https://www.nytimes.com/2018/10/06/arts/design/uk-banksy-painting-sothebys.html

[ban]
https://www.instagram.com/p/BomXijJhArX/?utm_source=ig_embed&utm_campaign=embed_video_watch_again

Checking the Cloud

...or "Hi, just wanted to see how my data looks like in the cloud".

Deserting the Antarctic

 Contribution to D. Good luck!

A beautiful Feature

...

Unequal conditions

I created this cartoon on behalf of Tennisclub Augst for their regular published small brochure. The more I look at it, the more I realize the interesting analogy it bears to completely different areas far outside of simple Tennis scenarios.

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.

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.

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

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.

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.

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

Management Decision Maker

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.

Use the tools

If you have the tools, use them

Everyday life at the Southern Hemisphere

People often ask me, how long it takes me to draw a cartoon. I cannot really provide a right answer here as it heavily depends. For this cartoon it took me only about 1 hour. This is very fast and also the number of drafts (only 2) is surprisingly low.  Usually, even though I am not a perfectionist, it takes much longer, probably 2 hours, but I've also worked on cartoons which took me 3 hours. I have stopped coloring my cartoons because this is an extra challenge at which I don't really excel. I mean, I have to spend a lot of time and the outcome is chilling. I think I do much better on some kind of grey scale. 

My daughter askmed me whether I drew the Orca straight out of my head. Of course, NOT. I cannot draw an orca just like this out of my head. I googled the web to understand the most important characteristics, then did two drafts and this is what came out. If I didn't do that, I'd definitly missed the white spots and put the eye at the wrong place. Below you see the "final" before I scan it into the computer and the very first draft.

Final version before scanning into computer

 

 

 Very first draft