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.

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