Wednesday, March 31, 2010

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

Tuesday, March 30, 2010

The Printer Test

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

Sunday, March 28, 2010

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

Saturday, March 13, 2010

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

Friday, March 12, 2010

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)

Thursday, March 11, 2010

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

Tuesday, March 9, 2010

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)

Wednesday, March 3, 2010

There is nothing like starting young

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.