Monday, May 21, 2018

Welcome to Weirdo-Land

I just wanted to draw an oldtimer Porsche Speedster 356 of the Fifties. Usually I am less addicted to sports cars, but this one is an exception. I watched an interesting report by Jay Leno about a 356 replica bulit by JPS Motorsports and since then can't take my eyes off it.

Thursday, May 17, 2018

Baffled sequenceIDs

Sorry folks, Insider. I don't know how I can better generalize the cartoon so it is also funny for those who haven't experienced our exciting moments we had with our love-hate relationship-sequence IDs. The counter was reset after each deployment. It resulted in duplicate numbering, hence kept us busy hunting for ghost bugs.

Tuesday, May 15, 2018

No undo in the elevator


A nice test pattern to apply while testing software, is to revert all changes performed on one object or more, either by sending the keys CTRL-Z as often as possible or by using any other provided cancel/revert/undo operation if it exists. An interesting observation for me still is the fact that until this day, I had never been in an elevator that provided the possibility to cancel your choice on pressed buttons... resulting in the experience of real "pain".




Sunday, May 13, 2018

Ready to take off - or good enough to go live?


Many, many years back, when I drew the first version of the cartoon on a draft piece of paper, I was inspired by an email sent out to everyone claiming the software is good enough to go live although the software never went through proper testing. Only "A." had tested it; and since A was such a great techie we were feeling quite comfortable if he had looked into it. This attitude had established more and more until we forgot to deliberating on the fact that even for "A." it was simply not possible to deal with all those increasing bugs showing up at customers. We had to change our mindset to simply rely on exploratory testing only, and therefore set-up a team that performed a more planned approach in testing the software. This included a study of all varying characteristics of the different customer's most important workflows, and it resulted on testing these workflows with the goal to mitigate the risk these workflows are broken in the next release.

Thursday, May 10, 2018

A lesson in Test Patterns

I recently had a workshop at the SwissQ offices in Zurich about common test patterns and how I am looking for bugs. I showed a draft of this cartoon, and this was the only moment where they were really laughing out loud...so I thought it might be worth finalizing the cartoon and publish it.

Thursday, February 22, 2018

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.

Friday, February 16, 2018

125000 clicks

We made it Yogi! I cannot believe that in these days I see 125000 of total and real clicks on my cartoon blog. Not enough to get famous (not my goal) but also not so few to get ignored..., thanX a lot for watching this blog.

I am especially happy having succeeded in banishing all requests to publish advertisment on this blog. I hope I can keep this for yet a long time.


Saturday, February 10, 2018

Mocking the Driver

Inspired by Tesla who "uploaded" their first car into space on Febrary 6, 2018. I haven't searched for any Tesla cartoons yet, but I guess there must be hundreds of similar ones around already. By purpose I didn't look for them, so I could fully concentrate on mine and not risk to accidentially copy someone else's idea. The picture of the moon is real and I shot it 2014 with my Russian telescope MTO 1000.

Sunday, February 4, 2018

Squares, Bowls and Triangles


I never forget the speech of a Google test engineer many years back, when he started with a slide that showed nothing but just all red colors. He took a chair and sat near the audience watching the wall together with us and said nothing. After quite a while he stopped the pondering silence and stated: "one gets used to red colors if you only stare long enough to it".

The point he was making here was to never accept your test scripts to report failures for too long. You should immediately address newly introduced bugs and fix those. If you wait too long, more and more tests may go wrong until very soon, you don't get alerted anymore when new tests fail. It may become a normal situation for your tests to fail. This is not only true for automated testing. It applies the same way to manual testing. If you get used to all the flaws and error messages an SUT (software-under-test) reveals, it is just a question of time until you arrange with it.

You don't see these things anymore after a while until someone with fresh eyes points you to all these known but weird things happening on your screen. You may then realize that you may have been reeducated softly. Ask yourself whether you still wear the hat of a customer or have you already turned from a quality focused engineer to an ignorant which - almost in trance - automatically clicks away all the noise. You may explain to yourself that these are all known issues reported in the past and someone will care about sooner or later. Really? Reality shows that these issues are long forgotten; although saved, but in a deep ocean called backlog where none can or wants to touch them anymore. If a bug sits in the backlog for a while, the likelihood for it to die increases. If a bug hasn't been fixed till now, it probably isn't important enough to care about.

Quite some time ago, when I realized that, me too, was just about to get used to quirks, exceptions and error messages, that pop-up like huge bubbles created by a hunting whale, I communicated my perception to the team and it was a shock when I noticed that others seem to have already "fallen in love " with all this puzzle of inconsistency.

As a result I asked myself, do I allow to adopt the attitude of the squares, or am I an ignorant bowl unable to accept things may be seen differently or am I currently just a triangle who struggles to take a decision.  I think I need a therapy... =;O)


Monday, January 22, 2018

Aspiring killer bugs

My relationship to bugs is two-folded, actually it is a love-hate relationship. I hate 'em because they nest everywhere. There are places where you definitely don't want to have them, regardless whether you like to hunt bugs or not. Even an enthusiastic software tester doesn't like to see creatures in production turning customer's lifes into nightmare. But fact is, there is no space in software where there isn't enough potential for bugs hiding until they take their chance and show their ugly grimace. They are like cockroaches. Even if you think you have destroyed them all, there is always a few left.

But of course I also love these little virtual critters. Without bugs I had no job, or let's phrase is a little less dramatic; I'd probably had a different job and not such a great time putting them on paper.

Not all bugs cause headaches, but some actually do. Even the less dangerous ones can be a pain if they they show up in a pack. The job of a professional tester is to find as much of the critical ones as possible. That means, you have to study them; you need to understand where they "live" and and how they develop. Bugs aren't clever (at least the software bugs) but they use every tiny little whole you don't carburize.  Some wholes are so small that you can hardly see them until the bugs crawl out and make your program crash or behave in a very unexpected way. Often, you need to apply good techniques that make bugs sell themselves out because you wouldn't find them otherwise.

People with little to no dedication making software a great user-experience will not only miss important bugs, they also make a whole team look bad in front of a paying customer.
The job is by far not done if you simply compare deliverables from software developers with incomplete acceptance critieria defined in user-stories.

One great technique to find bugs is to apply test patterns when you investigate a feature. You probably cannot apply all test patterns to every feature, because some don't make sense depending on the context, but if you continously test with a checklist in mind, you will soon realize how much more there is to discover behind an innocent looking user-story.

Test patterns are described in many books. James Bach talks about testing heuristics, James Whittaker walks through a software like a tourist in a foreign country. The book "Lessons Learnt in Software Testing" by Cem Kaner, James Bach and Bret Pettichord is a great source of information to help you develop great testing ideas. If you take testing seriously, you have probably already developed your own set of test patterns, sprout from past mistakes, observations, experiences or lessons learnt from other testers and hopefully you have further developed those patterns, so your detection rate further increases. The list will never be completed but getting better and better.

Saturday, December 30, 2017

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.

Friday, December 29, 2017

Bug or Feature?

Except from the text, the cartoon is not really my own invention, since there are plenty of VW Beetle pictures in the web showing a license tag with the letters "FEATURE", but it gave me finally the opportunity to raise a "monument" for my beloved old Volvo Amazon which unfortunately I don't have anymore.

Thursday, December 28, 2017

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.

Wednesday, December 13, 2017

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.

Wednesday, October 18, 2017

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.

Saturday, September 16, 2017

Stand-Up meeting in Antarctica

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

Sunday, July 9, 2017

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.

Tuesday, December 6, 2016

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?