Simply the Test

Giraffe Accessible, The Workaround

2012-01-14T00:17:00.000+01:00

A workaround was quickly found, although on the long run, it wasn't the most comfortable position.

Giraffe Accessible

2012-01-13T00:12:00.002+01:00

A reference to compatibility in general. For instance, browser compatibility. What works for FF, doesn't necessarily work for IE and/or other kinds of web browsers.

Deployment @ XMas (-Dinner)

2011-12-25T13:09:00.000+01:00

Whenever possible, I try to draw cartoons which win a smile from a general audience. This time it is probably too specific and therefore an "insider".

Sorry for that.

The Umlaut Test Pattern

2011-12-03T00:24:00.000+01:00

One of the most reliable "bugs" we meet regularly in our test department, is the so called "Umlaut" bug. Often we notice cases in our database which are displayed incorrectly. Namely Polish and/or German characters are regularly screwed up somewhere. Corrupt here means that it is displayed as a black square with a white question mark or a simple empty rectangle. The test pattern to look for broken text is effective at all test levels, be it it the UI or even at a lower level such as Web Service responses.

YU55 Near Miss

2011-11-09T22:43:00.006+01:00

I dare to ask about the consequences of an eventually failing asteroid observation software.

I think the good news is that there are a lot of amateurs out there who will use a broad variety of similar tools which calculate and “estimate” the same thing. If one of those tools fails, there is still a bunch of others who do it right.

Redundancy is the key to success sometimes. We usually try to avoid this in coding, but it has its place for instance at safety critical applications. But still, it needs a brain, common-sense and - believe it or not - capacity for teamwork, especially if you analyze inconsistent scenarios. Without one or the other, redundancy can also become deadly where it was actually meant to save lives.

The two altimeters in an airplanes cockpit work independent from each other. If one fails, there is still a high chance the other works. But if a hard-headed doesn't take into account that it may be HIS altimeter which fails and not the one of his co-pilot, then it may end up in a disaster like the one in 1990 where the DC-9 was flying about 900 feet (275 m) too low during approach and then hit high ground at Stadlerberg, near Zurich, Switzerland.

Where's the French window?

2011-07-23T21:55:00.004+02:00

Please excuse my short excursion away from my traditional cartoons about software testing. But this one is worth looking at, since it is related to testing indirectly.

My family and me just came back from a superb holiday trip at Greece Island Kos. We also made a short trip to Bodrum, Turkey. While we were eating traditional Kebap there, I looked at the building vis-a-vis and was wondering about the architecture of the balconies.

Something was wrong with them but I couldn't immediately figure out what it was. After a while I suddenly realized that the sea-side balcony at the second floor had no French window, meaning, it was unreachable. Then I saw that there was another one with the same "pattern" just below in the first floor. Fine, no doors. But why need a balcony there if you can't reach it? As a tester, my first thought was, it must be a bug, maybe an architectural bug,..no idea, just kidding! Maybe the two balconies where there just to achieve some kind of symmetry.

My theories didn't make sense and so I asked the waiter at our restaurant whether he can tell me more about this special "feature" at the white sea-side building vis-a-vis.

He didn't really see the problem outright and when he finally noticed, he stood on the sidelines for a moment . Then he explained to me what he was assuming. He thought the doors had been closed with masonry because of the strong wind and because of too much sun at this side of the building. Then I noticed him calling one of his colleagues and pointing to the abnormal balcony. Few seconds later a third colleague came by and all together were discussing excitingly the anomaly they/me just detected. After a while, the waiter came back to me and confessed that he'd never noticed this issue before even though he was working in the restaurant for several years. He and his colleagues, too, were fascinated about the missing doors and the waiter expressed to me some kind of amazement about how I as a tourist are looking at things.

When he said that, I immediately thought about James Whittaker who in his book "Exploratory Testing" often compares testers with tourists. Usually, tourists look at things differently than than those who live there here all the time. As a tourist you don't take things as granted. You are typically more curious and want to learn more about an area you've never visited before. This different view makes you notice things which people take for granted or don't know or care about. My plan is not to make too many relationships to the testing scene here but fresh eyes will always find new things, no matter how well you do your job as a software tester. At one point in time it is better to have someone else look at your "baby". If you know the SUT (software-under-test) too well you start to accept and tolerate things where others would move their eyebrows...This message is also for developers who don't think their code needs testing. =;O)

Testers meeting at the bar

2011-07-21T15:17:00.001+02:00

Testing is a thankless job. The tester's job is to tell a developer or a business analyst that "their baby is ugly" and it is difficult to stay friends after that.

If you try to be polite and ignore the ugly baby, it is just a matter of time until the customer faces you with the same conclusion or even worse when he states that ALL your babies are ugly.

A Trustworthy Invitation

2011-04-07T00:01:00.001+02:00

"2 chairlifts, one of them safe for children"...

Hello? Are you serious? Come on, I mean, a great place indeed, but not a prospectus that convinced me to leave my kids there for skiing, at least not alone.

What if we write something like this to our customers, each time we deploy / ship a new release to production, for example:

"500 new features implemented, 100 of them are tested"

OK, why not? At least, it would be the truth....=;O)

Early Checkers in the Cretaceous Period

2011-03-30T23:58:00.003+02:00

It doesn't matter what kind of tool you buy. Implementing and keeping test automation up and running for a long-term period comes with a cost that a lot of people did not expect when going for test automation. Whenever I had the chance to talk to people about test automation or even see what they've done or started to do, I recognized that most people tried to implement their own frameworks (me included), simply because what they bought or downloaded was not good enough or not easy enough to use for the tester.

Enriching your tool with a test framework that fits your needs is not wrong per se, but what most of my contacts had in common, is the fact that they started to automate testing on the Graphical User Interface (GUI) only.

That is funny, because the GUI is one of the most difficult and complex interfaces to automate for testing. The scripts are usually slow and the GUI changes often. Developers might embed components of different technologies and newer versions of it and your test tool might not (yet) support it. And then, developers start changing the GUI, re-arranging it, inserting additional dialogs that were not there before, etc. That is when a tester / test automation expert / framework developer / is suddenly more busy adapting existing scripts or the framework itself, than writing new test cases.

Doesn't this sound common: "Uhh, ohh that script does not work anymore because they have changed, this and that, so let us exceptionally execute this one test case manually because I need to have the report tonight. Maybe another test script is affected, too, uhh, ohh and may be a third and fourth test script as well".

I call this the Cretaceous Period of Test Automation. The scripts start to die one by one until you see so much red that you are attempted to question test automation and maybe even banish it and put the expensive tools back to the shelf.

I am not telling you here, that GUI Automation is bad. But there are other ways which can be more effective and easier and cheaper to maintain. For example, testing below the UI. This could be an API or a B2B interface (WebService), or something similar. If you are a lucky quality analyst who tests software components which provide a public interface to customers...use it for testing!
For those, who don't have APIs, ask for it, even if it is just for testing. We do quite a lot of automated testing on a WebService level. BTW, we did NOT abandon GUI automation, although my answer here may sound like we did. Of course not, we need it, but we are always trying to test the feature below the UI if possible. The API-Tests run on a daily basis and can therefore act as an early warning system. Something the big amount of UI scripts cannot do for us.

Of course, you always have to do the sort of testing / test automation that is appropriate for your needs and your situation, but at least you may think about the alternative of testing somewhere else than the UI.

TOJZ

My cartoon about this topic was also published at the "The Testing Planet" Magazine (March 2011)

Robots Learning Negative Testing

2011-02-08T17:00:00.002+01:00

Also published at the "Automated Software Testing Magazine", Issue March 2011

Unexpected Xmas Dinner

2011-01-20T22:07:00.002+01:00

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 Build Like Software

2011-01-04T16:38:00.007+01:00

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

2011-01-03T10:09:00.004+01:00

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

2010-12-03T22:34:00.009+01:00

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

2010-11-12T11:11:00.001+01:00

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

2010-10-25T22:03:00.005+02:00

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

Automated Testing 4 Oil

2010-10-18T10:13:00.002+02:00

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

2010-10-06T19:21:00.009+02:00

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 marked similarities to my job as a software tester and test automation engineer where we experience such situations almost every day...

Told Ya

2010-09-02T09:09:00.000+02:00

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

2010-08-08T23:38:00.004+02:00

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

2010-06-16T21:17:00.001+02:00

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

2010-06-09T23:40:00.001+02:00

Great innovations and lots of new ideas are emerging.

Behind the Scenes of Chaos Software Ltd.

2010-05-13T20:45:00.003+02:00

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.

It Works on My Machine

2010-05-05T22:58:00.004+02:00

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

2010-04-13T23:19:00.003+02:00

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

2010-04-13T00:08:00.005+02:00

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

2010-04-11T16:15:00.006+02:00

While I got some emails where people voted this cartoon as excellent, I must admit that there was quite a bunch of people who didn't get the point.

I don't know how the story of Aladdin is told in English spoken areas, but here in Switzerland and probably also in Germany you must use a cleaning rag and wipe it over the oil lamp (well here it's rather a teapot) to get the ghost out of it. In this cartoon it is the small bug that went over the teapot. He triggered the event for the Ghost to come out and of course, he didn't see anybody.

Cartoons that need explanation are probably not worth getting published but here I still think it's worth it.

Someone asked me whether ghosts really cast a cloud over the floor... Actually a good question. Don't know, I never met a ghost.

The Worm Catcher

2010-04-10T21:14:00.002+02:00

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

Tester at Psychologist

2010-04-08T21:21:00.000+02:00

...

Chaos Theory

2010-04-05T00:47:00.004+02:00

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

2010-03-31T22:25:00.006+02:00

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.

The Printer Test

2010-03-30T23:11:00.007+02:00

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

Invalid Test

2010-03-28T22:47:00.008+02:00

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

2010-03-13T23:18:00.008+01:00

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

2010-03-12T13:57:00.004+01:00

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

2010-03-11T23:09:00.005+01:00

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

2010-03-09T20:46:00.007+01:00

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

2010-03-03T00:00:00.005+01:00

I fully support that test automation plays a key-role for the testing team to cope with rapid changes. But I also see, is that many stakeholders in the software development process have an odd way of understanding the consequence of test automation. It doesn't come to you automatically.

While most management agree that test automation is important, interestingly many have no clue that efficient test automation (and also manual testing) requires the code to be testable.

Testability seems to be a foreign word and it is therefore not understood as being one of the key-roles to successful implementation of test automation. So, why is this important part not pressed ahead?

The opposite is often the case. Making the code testable is considered a low priority "feature" with the result that the effort to do test automation increases dramatically. And then people ask why the test team can no longer cope with the vast amount of changes. I hear phrases like "Oh, yes, that is a nice idea, but we will do this later". Later here means at a time none has the time anymore to do it and when it is too late for the test team.

Some also believe the fairy-tale that test automation saves tester resources.

In all those years being involved in a handful testing and test automation projects I realize an ever recurring pattern in this scene. The number of features grows over time and as a consequence also the number of test cases that should be executed.
However, since the number of testers remains a constant regardless of these facts it ends up with the testers limiting their activities on scratching the surface of the AUT instead of practicing the theories what all those testing certification authorities are trying to teach us.

I am usually sitting in a fast train that never stops and I can only hope that we don't hit the buffer stop with full speed like Toyota experienced recently.

So, where is the link to the cartoon? All evil starts with missing testability, and only today I have learnt once more that I was involved too late to bring in any meaningful testability features which could have helped testing more efficiently.

Hey Linda, when you read this, yes, this is the feedback I provided to your article at StickyMinds only today. By the way, I also read your other articles and you must know that your book was one of the very first I ever read about test automation, many years back.

Back From Skiing

2010-02-21T23:44:00.010+01:00

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

2010-02-09T09:11:00.000+01:00

Return of Nemesis

2010-02-08T10:07:00.004+01:00

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

2010-02-07T00:14:00.005+01:00

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

2010-02-06T12:53:00.003+01:00

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

2010-01-22T09:09:00.000+01:00

Problem on Prod2

2010-01-22T00:03:00.000+01:00

Think Positive

2010-01-09T23:29:00.000+01:00

We start the new year as we ended it. Full thrust into abyss...

Eat it

2009-12-16T19:34:00.012+01:00

Everyone expects testers to do a great testing job, regardless of whether you get the right information at the right time. There is not much you can do about it. I still remember Bart Simpson‘s phrase „You are damned if you do, and you are damned if you don‘t“. So, if you‘re a tester, you have to get familiar with the fact that you get the blame for defects that are left undetected, and developers get the glory if it works.

Under pressure, we accept that developers make mistakes and create bugs. Surprisingly we roast testers if they miss any, regardless of the circumstances.

Developers win laurels for fixing bugs that they have introduced themselves. How come?
Testers are here to find defects. Their real value is recognized often by the kinds of bugs they find. But it never gets published. Of course, who likes to confess that the system is buggy?

If the testers can't find any "great" defects anymore it can mean two things. Either the software is good enough for shipping or the tester missed some important areas for whatever reason. The problem here is that we will never know until the customer uses the feature or the program. There is always some sort of scepticism around because we never know whether the tester found all defects.

But if a customer sees a previously broken feature suddenly working, the users become enthusiastic and grateful even for simple things that should have worked correctly from the very beginning.

Don't Feed Your Plants

2009-12-11T23:56:00.000+01:00

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

2009-11-08T22:52:00.000+01:00

Engineering was about to execute a database migration script and we had tested it several times before on a separate environment. However the weekend had come where we shut down the production server to do our jobs.
My job was to make sure, after the migration, everything worked fine. There was only one problem. On that weekend, I had a problem with my VPN connection. It was essential for me because without connection it wouldn't be possible to test whether the migration was successful or not. When I raised the call I got a message saying that there is no support on the weekend for internal IT occurencies...
...Fortunately I could test without having the VPN, but I could not take part in the decisions and coordination of the process because my business email could not be connected anymore. Although I informed all involved parties about the issue and that they should send all related information to my private email rather than using my business email, I only got half of the messages. It was a small challenge to get all required information but I still managed to do the job. Still I asked myself what those guys are doing if someone decides to perform a DNOS attack on the weekend.
But I have to be grateful. What surprised me most was, that immediately on Monday, a nice guy from IT came to my desk and showed me how I could access our business email from home without the need of VPN....

Declining Confidence

2009-11-03T22:59:00.000+01:00

Wishful thinking.

Good Bye

2009-10-22T07:00:00.000+02:00

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

Imagine there is Pandemia

2009-10-13T00:08:00.000+02:00

If you followed my blog entry as of August 2, titled "What does Swine Flu have in common with Testing", you may remember the number of deaths the government was expecting...

...until today, there was not a single one.

Someone else's Bug

2009-10-12T23:15:00.000+02:00

Most of the real "cool" bugs that I find, usually don't show up during automated testing. They also don't show up during the execution of manual regression testing. Of course, both approaches are successful within the restrictions that are well-known. But the bugs that show up during in depth analysis of an already reported and hard to reproduce bug, often "generates" new findings of anomalies that I often didn't expect at this place.

To bring an example, my goal was to find the root cause of a particular error more and more customers ran into. It became a high priority when suddenly 100 customers were affected by it.

When analyzing real customer defects, my mind works differently than during normal testing activities. I have now a different thinking and ask questions like "Which scenario(s) is/are candidates that drive the application into the reported behavior.

While the functional testing techniques worked well without a customer in mind, the new approach takes the customer into foreground. I now wear a different hat. In order to understand what happened, I need to know how a customer uses the system in an end-to-end environment.

The first approach is usually to check the logs that help-desk provided and then hope to find the cause fast. The help-desk usually provides a log of one error at a specific point in time only. Sometimes you need more information, for instance, how did the user get that object he was unsuccessfully working on, who sent the object originally to him, who accepted it when and who forwarded the object at what time, who added data to the object, etc.

The log from the support gives you the necessary base information. Now I dig deeper into it to find more information about the object's "life cycle". Besides the client application log and besides the web server log files we have something like an Event-Log attached to each object.

The Event-Log provides information about which action has been executed by which user and in which state the object ended up after this operation. That sounds great but I've always had this strange feeling that something is wrong with this Log. There were too many inconsistencies and I feared I lose time while digging into this other area.

This time, I had no choice, I had to understand each action and each state it ended up, so I could reproduce the same scenario in our test environment. And since again, I couldn't quite follow up the weird order of the log entries and also the time-stamps didn't really make sense to me. It was now time to get into this new area of potential defects. I started to create an object from scratch. I created it and then immediately checked the event log and noted down which actions and states the event log produced. I append data to the object, sent it to someone else, pushed it through several web services and for each action made screenshot of the event log. Step by step I tried out varieties with the only goal to understand the patterns of the logs.

What I found was astonishing. My original assumptions are now confirmed. These entries are incorrect. To make it short, these entries didn't tell you the truth. When asking our support people whether they ever realized they ever realized the clutter in the event log sequence and time stamps they confirmed that they didn't like to read the logs because of the same reason I didn't look at it. They just could not follow these entries. I then talked to the architect which – to my surprise – confirmed that there are some known issues with the event log. Strenthend through this experience, I raised a bunch of new defects which were related to this Event Log. This was just one example. The truth is that I usually run into more such "side" effects

And now just happened what often happens while I am testing: I drifted away. I was out to find the root cause for a completely different defect and found a bunch of other new interesting anomalies which didn't have to do anything with the original defect.

BTW, what was the problem that I was originally out for testing?

Configuration Issue 2

2009-09-03T09:11:00.000+02:00

Password Expired

2009-09-01T22:38:00.000+02:00

If you ask me where I got the inspiration for this cartoon, then I must admit that it was quite a long detour to this scene. Actually you can't refer to one particular incident. How about the diplomatic affair between Lybia and the Swiss Government, where our Federal President is just about to learn some basic lessons.

Or what about that nice instruction from IT that makes us strictly not to put any passwords on paper and then hands out PIN codes to users on papers themselves?

Another example is that story of one employee that was passed to me after he saw the cartoon. He claimed to have access to a special server room which is important in case of emergency. When he came back from holiday, his access had been disabled. He spent an hour of investigation why he could no longer access the room, until he found out that IT disabled all accounts of which they could no longer find out the owners. According to him, it wasn't the first time. Luckily, until now we didn't have any emergency scenario where that access was needed immediately.

Functions As Designed

2009-08-12T06:46:00.000+02:00

Many customers have different requirements or requirements that change backwards and forwards over time, especially in an early stage of the project. The developer's weapon against such ping-pong requirement changes are :

make it all configurable

Whatever the customer sets is what he gets, even if the settings don't make any sense in their combination.

It is awkward if you have changes to existing behavior without noticing the parties concerned.
Testers raise defects whereas the symptoms are more a result of new features implemented and activated by default rather than actual defects.

We have an unwritten law that guarantees customers don't need to adapt their configuration files just to ensure existing functionality doesn't get changed due to some (unwanted) new features or restrictions in the use of some old existing features.

It is not only unpleasant for the customer, our test scripts won't work either. Well, that's the good thing of test automation. We wouldn't have detected those anomalies at the same speed as if we had done this test manually. However, we still struggle with a straight reaction to the findings. There are still some roadblocks to master.

What does Swine Flu have in common with Testing?

2009-08-03T07:23:00.000+02:00

The expected worst case scneario in Switzerland are 2 mio casesof Swine Flu infections (one third of the population) and about 5000 deaths. Is it really that alarming or are these messages alone already the disease?

What happens if the Swiss Health officials (BAG) warn us and nothing happens (as already seen with the bird-flu)?

What happens if they don't warn us and we're all left in a big disaster?

My work as a tester sometimes involved similar decisions (in a much smaller and less important world of course) when thinking about which priority / severity to set for a defect. If I continue to raise many defects with a high priority status, developers soon don't pay attention anymore, especially if a majority of the issues turns out to be far less important than initially rated. For the flu, if that disease is not going to come, people are going to pay even less attention to such warnings.

If I raise a defect and set it a lower priority, developers probably never look at it, because they have too many other important defects to work on.

I might have found an important security issue but not noticed its relevance. Neither may developers notice its relevance because I set it a low priority. It could be that someone else finds the issue and hacks the system. The consequences can be tough for the company. For the flu, if you don't warn people about a pandemia, the responsible officials get all the blame for the omission of informing.

As in most situations, what's left is a decision based on common sense. But I think it is also an egoistic one. Am I really out for raising all sorts of low rated defects? I will have to re-test all of them later at a moment when developers have finally worked off their stack of high priority issues and get over to fix the low priroity defects. That is happening at a time when I am in the middle of testing all the other high priority issues, and now I am the one who ignores all those low rated issues, may be for several months because there is plenty of other high priority fixes to re-test. You may get an email from an administrator who closed all the low rated issues, because none seems to take care about them and therefore he made the right decision. But what did you raise the defects then for?

Severity vs. Priority
When you as a tester think you found an important issue, it could be looked at differently by the business analyst or the developer or the customer or the project leader. Setting the priority is often a team decision as all team-members may be right or wrong.

A system crash might be a severe issue and rated a SEVERITY 1, because that feature is not usuable. But the customer may not use this feature in the next couple of weeks. That makes is far less important, hence becomes a lower PRIORITY, at least for a while.

On the other hand, you as a tester might find a bug of which you rate as not very important. The developer might notice it and understand that the issue will have severe (other) consequences if not fixed immediately.

Testers and developers may rate translation issues as not very important, but the Business Analyst may have a closer contact to the customer and know that users will not accept a system with tons of text pieces spread over dialogs that are not translated into the user's language.

Whatever you do, it is always a chain of thoughts before you make up your mind.

The Test Successfully Failed

2009-07-16T20:04:00.000+02:00

"The test successfully failed!" This is what my college sitting next to me was yelling lately. I smiled when I heard him, because a malfunctioning operation is typically everything else but a reason to see happy faces here. Of course, such is different for testers, at least it is for me.

My job is done when I broke the software I am testing. If I all my tests become a green status, I am getting distrustful. Can it really be, that all those tests passed? I mean, couldn't it be that I missed some important tests or didn't I test thorough enough? The possibility that the software could simply work as designed rarely crosses my mind. I even don’t trust my own test scripting. I am sure, my scripts have the same kinds of bugs that developers continuously add into our software.

At this point I remember an article where I read something about "False positives, and false negatives". Applied to my daily work as a test automation scripter, how can I find out quickly, whether my new or touched scripts will find errors if they occur and when the feature currently work fine?

We have a lot of scripts which test the API to our service based application and I found a really stupid but effective way to smoketest my own test scripts. I plugged out the network cable and started the test suite. In such scenario, I expect my complete test suite to "successfully fail" for all tests, but it was big surprise seeing one of the test cases to still get the green status icon.

I wasn't online and all my tests were supposed to submit and query information from a service that needs a network connection to get any meaningful results. How can it then be that this test passed without a network connection?

Looking closer at the validation/assertion the script was executing (hereby debugging my own code and trying to understand why this test returned a "passed" status) revealed that I was doing an assertion to an object that becomes the same state, no matter whether you are online or not.

For example, I was querying a list of items in a database which can be of either one or the other state. For simplicity let's take the states ACTIVE or INACTIVE.

The interface I was testing offered 3 parameters to pass to the API. Passing "0" gives me the INACTIVE items. Passing "1" gives me the ACTIVE items. Passing an empty string returns all items.

As our test environment is used by a many other testers, too, hence the exact number of items could not be determined at runtime unless you clean the database to start from an initial state.

That could not be done, because it affected too many people. Therefore I focused on testing the service by passing all 3 parameters in a sequence and then compare the number of items among each other. I verified that the total number of ACTIVE items plus the total number of INACTIVE items are the same as the total number of all items using the following code:

Assert.IsTrue(nNumTotal==(nNumActive+nNumInactive));

That checkpoint becomes (unexpectedly true) if I am offline because in such case, all the variables are filled with zeroes. Having said that, this test actually validated that

Assert.IsTrue(0 == (0 + 0));

The fix in my script then was to add an additional Assert-Statement that tests for the number of items being greater than 0.

Test Automation Side Effect

2009-05-10T23:55:00.000+02:00

I drew this cartoon a week ago not knowing that it is going to fit much better for a situation I experienced only few days later when we performed a migration test of a software component. I was instructed to perform just about 5 exemplary spot tests and I was told that I will yet be informed via email about the purpose and coordination of the tests planned for the weekend.

Actually I never got any emails, so I just prepared my scripts and extended those with additional checking code last Friday. My automated scripts existed of 300 test cases and I checked them on an integration test environment before they were ready for the big show. All I knew about this test was, it started at 1030h on a Sunday morning. I didn't know who was involved and I didn't know anything about what is going to change in the software component. On this sunny Sunday morning at 1030h (my kids running around in our garden and waiting for me) I was sitting in front of my laptop, waiting for the starting shot, that is, an email telling me that the productive master data has been mirrored to the Acceptance Test Environment.

This is a normal procedure when we test a patch or a new release. It is a signal for the testers to start creating snapshots of the system "before" (automatically and some manually). Actually, I didn't get any emails on that Sunday morning and I also didn’t get any of those announced emails on Friday.
I decided to execute my scripts anyway and start collecting the initial state of the system. In parallel I informed my boss that I still haven't been involved in any discussions of theses tests, nor who would be coordinator of those tests. Only minutes later I got an email from the sysadmin, stating that the migration on the Acceptance Environment is completed and that the testers can now start their tests......

...Wait a minute, wasn't I supposed to collect the initial state first? Well, then let's take the snapshot of the system "AFTER", instead. The results on the Acceptance Environment after migration looked surprisingly great. They didn't differ from earlier tests that I executed on Friday night while I extended my scripts and while I tested them on two different integration environments. That circumstance made me believe that the test on the Acceptance Environment must have been successful although I didn’t really do the "BEFORE/AFTER" comparison on the same physical system. The chance for the migration test to fail on the final system was minimal, I thought. Anyhow this test would still be necessary, that’s for sure.

The only issue that worried me at that time, was the fact that I noticed a really big performance difference between Acceptance- and Integration-environment. "Acceptance" responded 7 times slower than "Integration", although "Acceptance", according to engineering was a 1:1 copy of the final system, running on several nodes, while "Integration" only ran on 1 node. How can that be? When another tester reported, he couldn't confirm my discovery, I repeated my tests several times on both environments, each time confirming my previous conclusion. During this analysis I suddenly got another email from the sysadmin telling me that now also on the final system, the migration had been completed. Great...! Now I couldn't do the "baseline grabbing" on the final system either. All I could do was to compare the good looking Acceptance with the final system. The problem was that the two results were different, very different. 20 test cases failed. After some investigation I found the reason for 19 failed test cases.

Those "negative" test cases each expected an empty response (because they got empty response from all other test environments), but got valid data from production. After a short analysis this could be explained with the fact that not all data was copied from the final system to the test environments. Fine, but we were still left with 1 failed test where the final system returned a slightly shorter response than all the other environments did. After reporting the results (now I had the names of the involved people), the managers suddenly got nervous, and I mean really nervous. They wanted an exact explanation which we couldn't provide in such a short timeframe.

The managers decided to stop this exercise and instructed Engineering to roll-back. The suggestion of the team to start the test from scratch, this time giving testers a chance to collect initial state of the system and then compare the data of the same system after migration, didn’t get through anymore although this whole procedure wouldn't take more than 30 minutes. To my opinion, this decision was wise, given the circumstances that the communication and coordination of this test wasn't optimal.

At the end, what confused me, is this: I was instructed to do only 5 tests, I actually executed 300 and it ended up with one minor abnomaly. What would the decison have been if I only executed the other 299 that passed?

The other vexing scenario is that after I got the confirmation that the system was rolled-back, none asked me to test the rolled-back system.

After spending so much energy in summarizing this excercise I should of course spend a moment and look at myself. How could I have prevented such situation to end up like this? Probably it helped if I started to collect the initial state before the official test started, and – despite the fact that I wasn't involved in any planning/organization meetings/emails/telco, I could still have published my approach of testing to the people of whom I assumed, may be involved. If I had taken the chance to publish my approach of testing the migration/patch before, it may have helped driving the test into a different direction.

Don't Raise Any More Bugs

2009-03-15T23:37:00.000+01:00

Quit a few years ago, believe it or not, I was asked to stop looking for more bugs because it was difficult enough for the manager to "sell" the problems we already had.

"Knowing about more problems would make it more difficult for the customer to accept the release..."

and so I stopped looking for more...

Unconventional Appliance

2009-03-09T23:13:00.000+01:00

For those who didn't recognize what's hanging at the other end of the bar...it's a buiscuit, the shape of a bear (ursa).

Quite a year back I tried out some java script injecting by typing simple javascript commands directly in to messages that was part of the communication structure between fat clients and an online application-under-test. Whenever someone queried the list of items stored in the database, that piece of script was executed. The implication was a simple message saying "hello".

Users found it funny, some experts already knew it will become an issue sooner or later if javascript can be injected into one of the most important interfaces, but priorities were elsewhere. So, nothing happened for quite a while.
I decided to make it a little bit more obvious of what can happen and copied and edited the login page of our web portal, then published it on my own webserver outside the company. Then I injected the message by a javascript URL redirection to my webserver. The implication now was that users who queried the items in the list, got re-directed automatically to my "fake" logon page that looked exactly like the one from the company. Users who felt into this harmless phishing attack for a moment shrug their shoulders and then re-typed username and password into my logon page, not knowing that the POST request this time does something else, for instance storing their usernames and passwords. Real security experts laugh at this primitive phishing attack but I was shocked how easy that works. Amazingly although many testers and other users who were navigating on our test environment realized that something is wrong but none noticed the significance, or let's say the priority to fix this issue.

After quite another while I decided to make it again a little bit more obvious.. .I replaced the script instruction by an img-tag, hereby linking to a picture I found somewhere else in the web. Any person who logged on to the system and queried the database still received the queried list row-by-row, but one row now contained a hugh picture showing a crying ape with his mouth wide open.
This was in a list-column where only text was usually expected for display. Believe it or not, it didn't take long after that, until injection of such script tags was finally filtered. But it took more than a year until that issue was fixed.

Who's to blame?

2009-02-23T00:17:00.000+01:00

Sooner or later, either you or your team will be faced with the question, ..."How come that the testers haven't found this bug?" One thing is for sure:

Testers don't create bugs, those are implemented by the developers!

So, the question should rather be:

"Why do we allow developers to implement bugs? And why do we allow them to do it over and over again?".

I cannot think of a single defect where our testers don't ask themselves the question "How could I have avoided this bug to go un-detected" and then update their testware accordingly. But the number of test cases grows with the features while the number of testers is often a constant. What's left are priorities and supernatural smell for defect-finding...sometimes it just doesn't come up to everyone's expectations.

Greed Without Limits

2009-02-08T13:59:00.001+01:00

Inspiration for this cartoon came from an article by Daniel Binswanger, found in "DAS MAGAZIN", issued by the Basler Zeitung as of February 7, 2009):

"...Obwohl die UBS 2007 einen Verlust von 4,4 Mia schrieb, zahlte sie knapp das Dreifache des gigantischen Verlustes (12 Mia) als Erfolgsprämie an ihre Mitarbeiter aus. Wenn man diesen Irrwitz zum Massstab nimmt, erscheint das Salärregime 2008 tatsächlich von vernünftiger Bescheidenheit. Allerdings konnte sich der Schweizer Steuerzahler vor einem Jahr noch in der Illusion wiegen, der Grössenwahnsinn der Grossbanker werde das Privatproblem ihrer Aktionäre bleiben. Heute wissen wir, dass wir die Zeche zu begleichen haben..."

It is already the second cartoon on the topic of the financial crisis, but if you carry the thought a bit further, you might find some similarities in the business I am working in.

Fooling the Roboter

2009-01-18T22:15:00.000+01:00

Changing UI interface, unique names and IDs and position of UI controls, dealing with 3rdparty elements, etc, etc.. all this stuff is daily business for test automatin engineers.

Besides few smaller articles I published two more detailed articles on this topic on the US magazine Software Test & Perforance 2006 (pg 33 ff) and 2007 (pg. 31 ff).

Blurry Perception

2009-01-03T20:38:00.000+01:00

New Dresscode

2008-12-07T18:36:00.001+01:00

Ok, not related to testing, but accurate enough to the current financial crisis

Misconception

2008-11-23T18:35:00.001+01:00

Common misconception between testers and project leaders / managers.

There is never enough time and money to make things right from ground up. The weird thing is that there is surprisingly always enough of time and money to fix the problems later on.

Something missing in the release notes

2008-11-12T18:39:00.001+01:00

Unpleasant Discovery

2008-11-11T18:42:00.001+01:00

Invalid Use-Case

2008-10-06T17:05:00.002+02:00

How often have you heard the phrase "This is an invalid Use-Case" only to learn quite a while later that you haven't been far away from reality when such ignorance strikes back. Safety critical industries– by their nature - have a different approach in fixing problems in the long-term. They learn from defeat (watch full article)

Demystify Test Automation II

2008-09-11T21:49:00.001+02:00

London strike back

2008-09-08T17:26:00.001+02:00

1:1, now they downed the London Stock market

Recently in the server room

2008-08-13T17:17:00.001+02:00

Last night technicians performed some maintenance work on the air conditioning system in the computer centre and didnt tell anyone. They could not finish their work in time and left the server room with no cooling at all.
First room temparature SMS-warning received early in the morning (30 degrees C), then the second warning moments later, now 40 degrees, but of course none was reachable at that time. The servers shut down automatically when they "feel" it is getting too hot, but for 3 of the servers this was their last activity..., so this cartoon is dedicated to those 3 lonely servers who sweat to death...=;O)

Cern about to create black holes

2008-08-03T17:29:00.001+02:00

According to a news entry by CNN about a month ago, the most powerful atom-smasher ever built could make some bizarre discoveries, such as invisible matter or extra dimensions in space, after it is switched on in August.This collider, called the largest scientific experiment in history, is expected to begin test runs in August. at CERN in Switzerland. Some critics fear the Large Hadron Collider could exceed physicists' wildest conjectures: Will it spawn a black hole that could swallow Earth? Or spit out particles that could turn the planet into a hot dead clump?

David Francis, a physicist on the collider's huge ATLAS particle detector, smiled when asked whether he worried about black holes and hypothetical killer particles known as strangelets. "If I thought that this was going to happen, I would be well away from here," he said.

The collider basically consists of a ring of supercooled magnets 17 miles in circumference attached to huge barrel-shaped detectors. The ring, which straddles the French and Swiss border, is buried 330 feet underground.

Squirrel downs Swiss TV station

2008-08-03T17:24:00.001+02:00

These bugs are envious, they heard a squirrel managed to down the Swiss TV channel for at least an hour.

A difficult tester

2008-06-30T17:31:00.001+02:00

Testers should be curious and pessimistic, don't expect to win a lot of friends and don't expect them to see what you see.

Sahara

2008-05-26T22:09:00.001+02:00

It has been quite a while since I last put another cartoon on paper and the reason is not the missing subjects, that is for sure! There is quite a bunch of ideas just waiting in the queue to get shifted from draft to final mode. The cartoon is dedicated to UNICEF and will be part of the UNICEF exhibition next month in Steinen, Germany. The really interesting thing here is that - by accident- it fits so nicely to the weird scenarios I am just going through. Good luck, little birds!

Wrong Medicine

2008-04-12T18:48:00.000+02:00

When the best process becomes nothing but theory and deadlines are close. The title of this cartoon could have been "against-all-odds", but it is already the day after..when you get back what you have shipped...!

Different Views

2008-03-31T22:15:00.001+02:00

80/20

2008-03-27T17:53:00.001+01:00

If you were a developer, the text for you instead might be:

"Time's up folks!...now let's count the LOC (lines of code)"

New office / Extreme Squeezing

2008-03-19T17:51:00.001+01:00

All the employees were kept out-of-office for three days only to get this when they came back...

Acrophobia

2008-03-12T19:47:00.002+01:00

Zero Bugs

2008-03-12T17:47:00.001+01:00

A bad time for bugs, at least for some of them...

Ctrl Alt Delete

2008-03-12T17:40:00.003+01:00

SDTimes, N.Y. was so friendly to print this cartoon into one of their newsletters on April 1, 2008.

Not sure, whether that link still exists at:

http://www.sdtimes.com/content/article.aspx?ArticleID=31920

Robot shopping

2007-11-13T18:31:00.000+01:00

Alpha Centauri

2007-11-12T20:48:00.000+01:00

Demystify Test Automation

2007-09-24T20:59:00.000+02:00

Something About Coverage

2007-04-12T20:33:00.000+02:00

Minor Fix

2007-04-06T18:33:00.000+02:00

Victim of CMM Level 5

2006-12-11T20:49:00.001+01:00

When the CEO of announced that he wants to head to SixSigma level 5 I felt sorry for all those poor bugs. Finally we will have enough time to find all those little creatures and throw them out of the system. While drawing two poor bugs who lost their jobs – or who were finally detected - after checking for them I though the CMM Level 5 was probably more known.

Stealth Deployment

2006-12-06T18:49:00.005+01:00

This is a rework of a cartoon I drew in December 2006 based on a story that happened almost exactly like the cartoon demonstrates. I was "CC"-ied an Email which the head developer at that time answered to Engineering team. He forced them to deploy a piece of code while bypassing all agreed software deployment processes. And it wasn't the only time we suffered such actions. The original version of the cartoon together with one of my first contributions as an author was published later by BZMedia, N.Y.

90/10

2006-11-22T20:44:00.003+01:00

This cartoon was born the day after an IT-Boss invited 3 developers, 1 chief developer and his coder and the test team lead. The boss started to blame the chief developer and the tester for being held responsible for the delay of several software deliveries. According to him, those 3 people were responsible for losing $ 3 Mio each year. The chief developer was blamed for doing too much and delivering "even better" code always in the very last second, hereby risking to break running features and the tester was blamed for waiting too long with the test execution. This was such a ridiculous meeting because none of the people accused had any competence in deciding anything that could have impacted the delivery. It later showed up that this was just his last-ditch attempt before that manager had to leave the company.

No idea

2006-11-17T18:50:00.000+01:00

The challenge of getting the required information is well-known among testers. Even if you get the required documentation, what you really need is missing. I have seen a broad variety of documents with different levels of quality (from excellence to unusable) but the experiencie I liked the most was a project that combined two very different approaches in two different phases of the project.
The project started as an XP approach where the system was built from scratch; as the tester, I worked with developers and the project leader. During that time I learnt the application inside out, even though there was not much documentation around. After the program was shipped, we shifted to phase 2, from XP to a more classical approach where the developer and the BA wrote just rough specifications. After the initial version was built, I got release notes with valuable background information written by the BA and the developer. Even at a late stage in all the following phases, reading those release notes was enough for me to understand exactly which extensions were introduced and where I had to look for defects because I knew the application well from the first phase.

In another project that came with poor documentation, target users tested the system every six weeks for a whole week. During that week we delivered fixes every day and agreed on new features for the next iteration. The product quality was amazing. RUP and XP were foreign words at that time.
In cases were no or or poor documentation is around, I ask developers to present the features they have introduced rather than forcing them to write poor documentation that contains only half of the required information. Rather than focusing too much on requirements documentation, it is more imporatn to have the team close together and make sure you get the information you need to come a comain expert of the AUT.