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

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.