Unexpected Xmas Dinner

With this cartoon I earned an incredible number of feedback through email and some even came by my desk personally to condolate. While thinking it over I could hit the nail on the head even better by adding a speech balloon on top of one of the figures saying "Not again..."  as it wasn't the first business XMAS-Dinner like this. The last XMAS-Dinner or shall I say release plan was exactly of the same pattern.


The fact that the OK team now organized a separate room for the testers and the deployment engineers gives me plenty of new inspiration for some follow-up cartoons. ThanX to Janette Rovansek who was so kind to publish the cartoon at STP Magazine newsletter.

If Cars Were Built Like Software

ThanX to Rob Lambert (again) and Rosie Sherry who published my cartoon into the "The Testing Planet" magazine listed here at The Testing Planet

Confused Customer

OK, at the time I drew this cartoon, I thought, how would it feel if we testers suddenly got a call from a happy customer rather than the usual thing which is:

A P1 call on a Friday afternoon 4pm from a crestfallen customer after we deployed a new release the night before.

I asked myself, "how would it feel if we deployed a version that worked straightaway without any user running into troubles the day after we shipped the new release?"

Without expecting it ever to happen, only a few months later, we got forwarded an email from a customer who congratulated us for the great achievement. He was happy because we delivered a piece of software which worked at first go. The customer was surprised, since he did not expect this from us, so he felt he needed to tell us how amazed he was.

What does it tell me? It's obvious, that message was ambiguous. Did he really want to simply be grateful or did he want to tell us something else...?

BTW. ThanX to Rob Lambert who was so kind to include my cartoon into the free eBook "A Tester is for Life, Not Just for Christmas".

Minor Risk Patches

Testers like to demonstrate that the software is not ready to ship (yet) but sometimes they fail miserably by making it clear enough..., and the customer might get a nasty surprise.

Vito, my colleague, once said: "Hey, we're really good at working wonders, but sometimes, it just acts up.

The Unexpected Ugly Bug

I remember the time where we had a set of only few automated tests and a big set of manual test cases. As the number of features grew also did the number of test cases. The number of available testers was a constant number and we didn't manage to execute all the test cases. At that time I started to rate the test cases based on their likelihood of detecting bugs. Whenever we executed a test case that helped uncovering a bug, we added a link to the defect's ID. Each time the test suite was executed again, the tester was notified about the number of defects and its priorities it found in the past.

That was a practical approach, but also a risky one if I think of what just happened to me last week at my current employer.

I had an automated test script which couldn't be executed due to some problems with the new version of the test automation framework we were using. Since there wasn't enough time to investigate, I just skipped this script, reported "FAILED due to unknown reasons", marked it as low priority and continued with other tests. I did it because the component it was testing never showed up any defects in the past and so I thought, I could easily put it aside for a while until I found enough time to investigate what was wrong.

When I finally had the time and managed to "revive" the script, it uncovered a real ugly bug, and it was almost too late to fix it for the release that we were about to deploy. My luck, the release-deployment had to be shifted by one week due to another issue and it wasn't a big deal for the developer to fix it.

Anyhow I felt uncomfortable for the fact that I found this issue so late in the process whereas it could have been uncovered much earlier. What does it tell me? Even a test case / script which may look useless for many test cycles, may become an important script at a later point in time. Today, while writing or looking at new/existing scripts to determine its priority, I ask myself..., what could go wrong if that script isn't executed rather than thinking of the success rate in terms of "how many defects did it uncover in the past".

This cartoon along with the text is now also published by the STQAMagazine's blog
(and later on, also in the STPMagazine print version of January 2011 (first page)).

Revolt of the Test Scripts

If testers are not invited early enough, they will not have the chance and the time to determine whether or not they have to adapt their existing scripts. As a matter of fact, some scripts will have to be de-activated since they start to report errors that aren't any. Someone smart once called this "False negatives", consequently the opposite exists, too (false positives). see also the blog entry as of July 2009 (The Test Successfully Failed).

...by the way, Test Tools and/or your own test scripts can be buggy, too (here a false negative).

...in the meantime, I found out under which conditions this situation occurs. In the NUnit Test Automation Framework, even if all your test scripts were running fine the whole suite may report a failure if someting goes wrong outside the test suite. The TearDown function is such a method that gets called automatically after each script and/or after the suite is completed. At that point, all scripts reported already a successful run, but the TearDown can still throw an exception if for instance your implementation invokes a call of a null object (null pointeer exception). In such case, NUnit reports a failed suite although all child scripts were passing all tests.

Automated Testing 4 Oil

 It is easy to build up a new test automation suite from scratch. It is a different story to keep it up running for a life-time. Changes in the software under test will be implemented. One day your scripts need to be adjusted to the new situation. Some scripts will become obsolete, some new scripts need to be added, some just don't work anymore.

The more test cases you have the more difficult it is to keep them up-to-date and make them provide the same benefit they did at the time they were born and run successfully. More and more scripts will start to fail and if you don't have the time to analyze the root-cause and fix the scripts, the number of scripts printing red alarm signals increases.

You will start to become familiar with the fact, that some scripts always print red warnings and the day isn't far where you don't even notice anymore that more and more scripts suffer of the same issue.
Probably you don't even trust your scripts anymore since they may report so called false-negatives. Make sure you keep them up-to-date at the time they fail. We call that script maintenance, and yes, this not only applies to manual testing. It is especially true for automated testing, too.

This is my second cartoon published in a printed magazine (STQA Magazine, September/October 2010). 
ThanX to Rich Hand and Janette Rovansek.

Mission Impossible in Paris

I just came back from a holiday trip in Paris where we met good old friends from Scotland.

While I could relax from the stressful tester's life, I had a nice déjà-vu on my last day at Paris in the Centre Pompidou.

My kids were playing with a conveyor machine in the playing area where you could pick up colorful everyday items out of a big repository and put it on the conveyor band. Someone could then turn the wheel and all those items got transferred back to the repository. 

What first looked like a boring task to me, appealed so much to my kids and other children that it was hard for me to get them away of the play zone and enjoy the beautiful exhibition. However, the wheel of the conveyor regularly blocked so the kids were no longer able to turn the wheel. As a consequence, no items could get transferred back to the repository. The reason was the stack of items in the repository gaining so much height that it reached the thin vertical slot of the conveyor after only a short while of running. Due to the kids continuously pulling the wheel, some items were involved into the slot and blocked the machine completely.

I spent most of the time making sure, the stack was kept at a safe height so nothing could disappear into the slots, hereby making it easier for the kids to play with the conveyor on a continuous basis. While doing this, I realized another small item got stuck in the slot but did not cause the conveyor to block completely. Instead it slowed it down. The kids had to put a lot of forces on pulling the wheel, so their items got transferred back in the repository. I was trying to get the "bug" out so the kids had a lot easier job.

I failed miserably, because none of kids could stand still for a moment. I had risked my fingers each time I tried to get the "bug" out of the slot. Whenever I almost had it, another kid took control over the wheel and caused me pray for my fingers. Surprisingly, I was the only one parent trying to help those kids and keep the machine running smoothly. When I finally decided to step back and watch the scene from a distance, I saw kids trying to pull the wheel even harder when it no longer worked. None really took the initiative and scaled down the size of the stack.

Thinking about that issue, it could have been easy for the local management to fix the problem. First there were way too many items in the repository. Fewer items had solved the issue because the stack never had a chance to grow up fast and so high up. In other words, less items in the repository and the conveyor never had such a continuous maintenance problem. Second, none really seemed to care about a badly moving conveyor. Instead of someone stopping the kids from using the wheel for just one minute and trying to solve the root cause that slowed down the conveyor band, local management just accepted (or wasn't aware of) the fact, that those poor kids had to "work hard" and spend too much effort.

At this moment I realized the remarking similarities to my job.

Told Ya

It can be both, frustrating and encouraging if you see a software package getting rolled-out / deployed, without ever having passed the hands of a tester.

Frustrating because you couldn't convince anyone to roll out an untested release.

Encouraging since you get an immediate demonstration of what are the costs of a missing tester.

Less Room for Bugs

We have automated UI tests, keyword driven, reflecting exactly the user's workflow as they use our programs, or let's say exactly the way we believe the customers still use them.

In addition we run component tests below the UI (WebServices), automatically invoked by a continuous integration server, covering nearly 100% of the interfaces that our company offers to our customers and to make our systems testable from below the UI.

Also we regularly execute manual tests on an end-to-end basis to complete our "spectrum" of available testing techniques....any yet....bugs still make it through to the field.  There is not much we can do against it. This is just an accepted fact, no matter how much effort you spend in trying to avoid it.

As a tester I celebrate if the software goes belly up, but of course only if this occurs during the testing phase. As all other contributors to writing/developing software components and systems, me too, are "praying" that we don't get any surprises, once the software is shipped or deployed online. If customers find reasons to complain in spite of all our applied strategies in stopping severe bugs bothering them, it is our performance of duty to question ourselves and our activities each time from scratch.

The one question which always stands out is "Could we have identified this particular bug before the customer had the pleasure to experience it?". In most cases I must add, we could not, and the reason is obvious:

Following a plan and assuring execution of all agreed test cases within the time given does not guarantee that new bugs impacting our customers workflows can be ruled out. In our particular situation I see an increasing number of bugs slipping through due to poor communication to the testing department. If testers don't know what features customers are using and how, then how can one expect the testers to check the right area? Well, the good thing about such bugs is, that we learn from them and ask the right questions. That bug will surely not show up again since it is now covered in the test suite, so which one will show up next...?


By the way, this cartoon is my first cartoon that got published in a PRINTED magazine. ThanX to "The Testing Planet" aka. softwaretestingclub.com

Vuvuzela Testing

Software Testing here not only happens under annoying background noise, it is a great challenge for people who want to test their nerves under a constant exposure of weird irradiation.

Do-it-yourself Virus

Great innovations and lots of new ideas are emerging.

Behind the Scenes of Chaos Software Ltd.

If you are familiar with Gary Larson you might recognize the scene as close related to one of his creature cartoons where the dinosaur stands in front of its calendar striking each day out ("kill something and eat it"). I hope Gary forgives me for the similarities, but the scene fits perfect to our common experience.

IWOMM - It Works on My Machine

I am sure that any tester has received a message like this at least once in his life as a tester. But to be honest, it happened only rarely to me.
Such a rare incident occured recently when we detected an optimistic lock exception in one of the WebServices under very specific caller scenarios on one of our integration test environment.

However, the developer could not reproduce the error on his workstation and although he was  already running a newer version of the code, he was actually right.

It turned out the problem occurred on a clustered environment only where several containers and nodes are running in parallel. Lesson learnt: It doesn't need to be the programmer who broke a piece of software. Sometimes other influences lead the software to behave different. Here it was the environment in which the software was running.

Defibrillator

Actually a good idea to install a defibrillator at a place where all hell breaks loose with this never ending deployment virus . I just hope, none gets the idea of using this machine to improve test efficiency and giving some testers an extra shake...

Different Goals

When a tester didn't find any cool bugs, then he basically has two options to think about.

a) The software is good enough to go live
b) The software wasn't tested well enough

Typically, the developer thinks it is "a". And, of course, the tester always fears it could be option "b".

Very First Exception

I received a few emails where people voted this cartoon as excellent, but I must admit that there was quite a bunch of people who did not really understand the punch line.

I don't know how the story of Aladdin is told in English spoken areas, but here in Switzerland you must use a cleaning rag and wipe it over the oil lamp (in the cartoon it is a teapot) to get the ghost crawling out of it. In this cartoon it is the small bug that went over the teapot. He trig-gered the event and the ghost slipped out. He was confused as he did not understand who woke him up.

Another one asked me whether ghosts really cast a cloud over the floor... Actually a good question. I don't know, I never met a ghost in person.

The Worm Catcher

I'll better not comment this one, may be at a later point in time.

Tester at Psychologist

...

Chaos Theory

It was quite a challenge identifying this hustle and bustle with a unique and accurate name, until Einstein crossed my mind...

Magic Black Box in Your Car

Many car owners probably have not yet realized that their new cars are already equipped with blackbox systems which have lots of sensors and log many operations executed by the driver.

The question here is, who is actually "watching" you.

According to TCS (Touring Club Schweiz) there are reported cases where car owners lost their warranty claim just because the manufacturer could prove they have stressed the motor by driving in a suboptimal gear.

Source: Tagesanzeiger, March 11, 2010
Direct link: Wer ein neues Auto fährt, kann nichts verbergen

The Printer Test

Every other two years we start inventing new processes which don't solve the problems we introduced with the previous processes.

Invalid Test

How often have you run into a weird behavior of the SuT and then tried hard to find evidence for this phenomena? Developers sometimes just don't believe you until you can prove with a video. Screen shots are no hard facts anymore, since they don't demonstrate what steps you have done aside.

The time that can be spent into investigation can grow dramatically. The more time you spend into finding the root cause, the more pressure on you to be successful so the time spent for searching is justifiable.

Woe betide you if you can't find it after so much time has been wasted.

Woe betide you if you cannot find the bug but the customer will.

Woe betide you if you found the bug, reported it, but someone still thinks it is reasonable enough for the customer...and then the customer doesn't like it...

Husky Adventure in Oberwald Switzerland

For one time, something different to let it all hang out. I made these (and many, many more) pictures today at Oberwald, Wallis (Switzerland).

Rose Colored Glasses

The biggest shock to most industry candidates is the sheer size of the test discipline at Microsoft and the amount of clout they wield. The developer to tester ratio at Microsoft is about 1 to 1. Typical for industry is about 5 developers to 1 tester and sometimes 10 to 1 and higher.

When you are outnumbered like that, a test organization is usually focused on survival rather than evolving their engineering skills and practices.

Source: How We Test at Microsoft, MicrosoftPress (Page, Johnston, Rollison)

How to confuse intruders and keep them away from your site

Some improvements have been made to improve security of our web site by suppressing detailed information of what went wrong during a B2B transaction, or by providing information that is useless to attackers. While the information provided before was helpful for support and testing for quickly finding the root cause of a failed data upload, this has become almost a mission impossible and the reactions, namely from support came promptly.

(c) Mueller & Zelger

The Exciting Job of a Tester

Testers like to hunt for and find stuff. The hunt is exciting, and finding an error is the ultimate motivation.

If you work for the type of organization that is not focused on quality and does not recognize or fix anything your testers have worked so hard to find, a test team is going to view that as a lack of respect for them or their work. And if you don't give your testers the respect they deserve, you'll demoralize them pretty quickly.

Source: Beautiful Testing, O"Reilly ("Was It Good for You", by Linda Wilkinson)

There is nothing like starting young

Test automation plays a key-role in buidling great software, especially in today's rapid delivery cycles. What works today, may be broken tomorrow. But while most managers agree it is important, many struggle investing accordingly or do not understand that they have to support the testers while asking for testable code. Making code testable is often seen as something less important than delivering features quickly.

Testability is a foreign word although it is the key to successful test automation. I have heard phrases like "Oh, yes, that is a nice idea, but we will do this later". Later here means either never or at a time when it is already too late and becomes too costly to implement it.

Some also believe test automation saves tester resources. That's not really true, because test automation enables you doing tests you would never have hired any test resources for anyway. Test Automation enables you doing things that 100 testers couldn't do, that's right, but you would never hire these testers anyway, so you cannot talk about "saving tester resources".

Test Automation actually saves resources, but not really at QA. Test Automation enables you to point out failing code right after it is committed/checked-in. So, this happens at a time a developer still remembers what he just did. He can correct the error with no big deal. Without automation you would notice the same errors days or weeks later. At that time, the developer already moved on with different stuff and hardly anyone may know who broke the code or what piece of code is responsible for the detected anomaly. An expensive analysis and debugging starts where not only one but liklely more people are involved investigating the issue. These are the costs you can avoid with automation, but never say it saves test resources.

Back From Skiing

No fun today. Just came back from my family winter holiday in Engadin, Switzerland. I shot tons of such pictures with my Canon 40D and wide angle lenses from Tokina (11-16). On the left: Julia Pass, on the right: La-Punt Chamues-ch view towards Samedan and St. Moritz)

Consequences of Nemesis at the Arctic

Return of Nemesis

Last autumn I visited a fascinating speech of a Swiss astronomer at the University of Basel.
He explained the theory that our Sun may have a twin star moving in an
huge elliptical orbit and may be held responsible for the mass extinction of the dinosaurs.

Here is a very good description of Nemesis which I found on WIKI:

Suppose our Sun was not alone but had a companion star. Suppose that this companion star moved in an elliptical orbit, its solar distance varying between 90,000 a.u. (1.4 light years) and 20,000 a.u., with a period of 30 million years. Also suppose this star is dark or at least very faint, and because of that we haven't noticed it yet.

This would mean that once every 30 million years that hypothetical companion star of the Sun would pass through the Oort cloud (a hypothetical cloud of proto-comets at a great distance from the Sun). During such a passage, the proto-comets in the Oort cloud would be stirred around. Some tens of thousands of years later, here on Earth we would notice a dramatic increase in the the number of comets passing the inner solar system. If the number of comets increases dramatically, so does the risk of the Earth colliding with the nucleus of one of those comets.

When examining the Earth's geological record, it appears that about once every 30 million years a mass extinction of life on Earth has occurred. The most well-known of those mass extinctions is of course the dinosaur extinction some 65 million years ago. About 25 million years from now it's time for the next mass extinction, according to this hypothesis.

This hypothetical "death companion" of the Sun was suggested in 1985 by Daniel P. Whitmire and John J. Matese, Univ of Southern Louisiana. It has even received a name: Nemesis. One awkward fact of the Nemesis hypothesis is that there is no evidence whatever of a companion star of the Sun. It need not be very bright or very massive, a star much smaller and dimmer than the Sun would suffice, even a brown or a black dwarf (a planet-like body insufficiently massive to start "burning hydrogen" like a star). It is possible that this star already exists in one of the catalogues of dim stars without anyone having noted something peculiar, namely the enormous apparent motion of that star against the background of more distant stars (i.e. its parallax). If it should be found, few will doubt that it is the primary cause of periodic mass extinctions on Earth.

Some scientists thought this Nemesis theory was a joke when they first heard of it -- an invisible Sun attacking the Earth with comets sounds like delusion or myth. It deserves an additional dollop of skepticism for that reason: we are always in danger of deceiving ourselves. But even if the theory is speculative, it's serious and respectable, because its main idea is testable: you find the star and examine its properties.

There are programs running where astronomers are searching for the star. If the deamon star exists, we will surely know within the next two years.

How the Mighty Fall

On the occasion of recent problems with Toyota, Akio Toyoda, new corporate CEO at Toyota, cited a few phrases of Jim Collins' book "How the Mighty Fall". He also estimated that Toyota has reached already level 4.

Nespresso Again

You may remember my last years post titled "Don't feed Your Plants", where the gardeners complaint about the fact that some people seem to feed their plants with coffee.

Since our plants feel so sick, the company has now decided to let the gardeners check the flowers every other third week.

So, my dear plants...no more coffee, is this clear!
=;O)

Phone Conference

Problem on Prod2

Eat it

„You are damned if you do, and you are damned if you don‘t“ (Bart Simpson).
That phrase matches perfect to software testers. It doesn't matter how many great and cool bugs you find. If you miss one, you will find yourself in a defensive mode where you have to explain to managers why you missed it. I have rarely seen anyone asking a developer why he introduced that bug and why it took so long to fix it.

Under pressure, we accept that developers make mistakes and create bugs. Surprisingly we roast testers if they miss any, regardless of the circumstances. We are not even asking under which conditions they had to test. Did they have the right information at the right time? Were they given any chance to test at all or was the new version deployed without asking a tester to look at it?


Funny though, I have seen several times people to celebrate developers for fixing bugs they had  introduced themselves. This scenario is especially common if the bug was disturbing for a long time. When someone finally fixes the ugly bug, people leap for joy. They are greatful for simple things that should have worked correctly from the very beginning.

Don't Feed Your Plants

Once a month, the gardeners come into our offices and take care about the tortured plants.
As we all know, plants in IT departments often put up with everything, either they suffer thirst, or near-drowning and they serve as a trash for many weird left-overs.

That is no different in our offices. Programmers and engineers drink so much coffee, especially when it is free, and they like to share it with their plants...until it gets detected...

Houston, we have a problem

This cartoon (2009), was the reaction of a weird response from our service desk while we were doing a database upgrade on the weekend. My job was to do the final test on production. But, my VPN didn’t work anymore. When I reported the problem to our internal helpdesk, they responded by clarifying that they do not provide any support over the weekend. Although I could test anyway, I had no possibility to join the conversations between DevOps, Developers and the IT-Manager. Somehow I still managed to get them send me their news and instructions to my private email account, but still I received only half the information and I wondered what the company does if hell breaks loose? Do we still stick to office hours in such cases?

 But, I learnt, that I am not alone. The Swiss armed forces had a similar issue 2014 when a Boeing 767 flying from Addis Abeba (Ethiopia) to Rome was hijacked over Italian airspace and diverted to Switzerland [1]. The plane was escorted by an Italian and French fighter jet until the passenger plane landed safely at the Swiss airport Geneva. And where were the Swiss F/A-18 Hornets? Oh, their pilots work only from 8am to 5pm with a 30-minute lunch-break. This incident was broadly discussed in public and a lot of jokes made the rounds. But, in contrary to my case, the Swiss armed forces had learnt from this embarrassing incident and now provides a 24/7 service [2].

 

 

 

---

[1] Ethiopian Co-Pilot Hijacks Jet, Then Asks for Asylum in Geneva
https://www.nytimes.com/2014/02/18/world/europe/hijacked-ethiopian-plane-lands-in-geneva.html

[2] No more office hours for Swiss air policing missing
https://www.aerotime.aero/articles/26815-no-more-office-hours-for-swiss-air-policing-missions

 

 

Declining Confidence

Let's assume someone has a brain fart and suggests to convert all bugs into tasks, only to get rid of the bug backlog. Gone are all the bugs in a second. All of a sudden you produce bug-free software. What a great achievement.

Another product manager cleaned his backlog by converting all bugs into tasks only for time sitting in a meeting with the release manager. He had less to explain then. When the meeting was over, he moved the tasks back to bugs. Believe it or not, this really happened and this scenario reminded me to “Patriot Games” with Harrison Ford playing a former CIA agent. One scene was about a terrorist training camp in the desert. The chiefs knew the exact times when an American espionage satellite flew over their area. They hid their weapons and anything that seemed suspicious; then they holed up in their tents until the danger had passed.  
 

Good Bye

In loving memory of a very good friend of mine and my family and who passed away all of a sudden, leaving an elusive new situation for his wife, his two children and a big number of good friends.

T.

Publish Post