I mean, the World Cup is over and nobody really cares about baseball until September, so perhaps this could help fill the competitive void in the meantime…

Here are the current “standings”:

1. Apple
2. Oracle
3. Microsoft
4. HP
5. Adobe Systems
6. IBM
7. VMware
8. Cisco
9. Google
10. Mozilla Organization

As noted earlier, this is really more of a marathon than a sprint, so it would be useful if we went back a little longer than six months to crown a winner. Thankfully, Secunia did just that as part of their key findings:

• Since 2005, no significant up-, or downward trend in the total number of vulnerabilities in the more than 29,000 products covered by Secunia Vulnerability Intelligence was observed.
• A group of ten vendors, including Microsoft, Apple, Oracle, IBM, Adobe, and Cisco, account on average for 38 percent of all vulnerabilities disclosed per year.
• In the two years from 2007 to 2009, the number of vulnerabilities affecting a typical end-user PC almost doubled from 220 to 420, and based on the data of the first six months of 2010, the number is expected to almost double again in 2010 to 760.
• During the first six months of 2010, 380 vulnerabilities or 89% of the figures for all of 2009 has already been reached.

ZDNet’s Adrian Kingsley-Hughes made note of the products that are causing these vendors to rise or fall in the standings. The culprits, he says, are as follows:

• Apple - (iTunes, Quicktime)
• Microsoft – (Windows, Internet Explorer)
• Sun Microsystems – (Java, now part of Oracle)
• Adobe - (Acrobat Reader, Flash)

So testers, who do you see as the Bug Marathon winner (i.e. loser) at the end of the year? Not that we’re keeping score or anything.

The Cost? $18.2 million (in 1962!)

The Bug? Omission of a single overbar

The Mariner I was the first spacecraft of the NASA Mariner program that “launched a series of robotic interplanetary probes designed to investigate Mars, Venus and Mercury (Wikipedia).”

The bug that brought the mission to its speedy end was carried out by a programmer, who while transcribing a handwritten (in pencil no less) formula into code, missed one single overbar (or as it’s less-technically known: the hyphen).

NASA’s public account of the software glitch is written as follows:

The Mariner 1 Post Flight Review Board determined that the omission of a hyphen in coded computer instructions in the data-editing program allowed transmission of incorrect guidance signals to the spacecraft. During the periods the airborne beacon was inoperative the omission of the hyphen in the data-editing program caused the computer to incorrectly accept the sweep frequency of the ground receiver as it sought the vehicle beacon signal and combined this data with the tracking data sent to the remaining guidance computation. This caused the computer to swing automatically into a series of unnecessary course corrections with erroneous steering commands which finally threw the spacecraft off course.

Fortunately, the mission was successfully completed by Mariner 2 five months later, but it’s hard to ignore the significant costs brought about by a mere hyphen. Do you have any bug stories like this one? Has a missing bar (or something equivalent) ever led you to a messy debacle?

According to The American Bankers Association, all of $763.9 billion — more than six times the total assets of First Chicago NBD Corp. — was the largest error in US banking history.

And the reason given? Inadequate testing of course! The bank updated its ATM transaction software with new message codes. The message codes were unfortunately not tested on all ATM protocols, which resulted in some ATMs interpreting the codes as huge increases to customer balances.

This isn’t the first time we bring up banking bugs. You might remember Software Bugs: You Win Sum, You Lose Sum, the post about a man in Orlando who while making a routine bank transfer was shocked to see his balance at $88,888,888,888.88.

What other bugs have you recently heard or read about with such huge financial implications? Any mobile banking bugs?

You have also been very naughty. Check out this Twitter entry written by you:

I kill people who nudge me

Wait, that wasn’t written by you? It was written by someone else named You? Oh, our mistake. And apparently it was Twitter’s mistake too according to this article on TechCrunch.

Twitter likes to tell you who is doing what and when at the bottom of each tweet. For example, a post description might tell you that it was retweeted by a friend.  Or if you were the one doing the retweeting, then the post description should say that it was retweeted by “you”.  But what happens when a buggy hyperlinking algorithm decides that anything after the words “Retweeted by” should link to a Twitter profile?

“Retweeted by you” becomes “Retweeted by you” – as in twitter.com/you. And you sounds cranky.

There are a lot of good lessons here for testers and developers, but I want to highlight a few particular:

1.) Try to think about all of the use cases, not just the obvious ones. This bug would never appear if a tester just browsed a Twitter feed looking at everyone else’s entries. To find this bug, a tester would have to retweet something themselves and then check the output.

2.) Testers should always think about the big picture. A narrow-minded tester would simply make sure the hyperlinking algorithm worked by checking the output for a few sample retweets. Once the tester saw the links were correct, they would say the algorithm was good to go. On the other hand, a big picture tester would look at how the single algorithm affected the overall user experience from start to finish.

3.) Go beyond just looking at the application – interact with it! This bug also appeared as a problem with the pop-up hovercards that appear when you move your mouse over a Twitter link. By simply hovering your mouse over “you”, Twitter asked if you wanted to follow “you”.  You should ponder that paradox while writing that bug report.

Do you have any other lessons? You the reader?  Not you, this guy.  He sounds unhappy.

Why? Well, if you are an experienced QA professional, you know exactly why.

A recent article about how to write a useful NHTSA (National Highway Traffic Safety) complaint should strike a chord with software testers. The complaint template is very similar to the bug reports we all know and love. In fact, they both serve the same purpose: defect reporting.

Consumers can learn a few lessons from software testers – and vice versa – by taking a look at some key excerpts from the article:

Include data that will help the manufacturer better understand the problem:

• Facts about your vehicle and maintenance records
• What you did and how the vehicle responded
• Evidence and extra details

Exclude information that does not help — at all:

• Multiple problems in the same complaint
• Your feelings (anger, frustration, nervousness, etc.)
• Spelling errors

If you follow the uTest blog, you may have come across a well-written post by guest blogger and uTester Joseph Ours: Respect the Defect: Advice that will change the perception of testing. The philosophy of proper defect reporting is well described by Ours, and may be a great primer for consumers filing NHTSA complaints (though we hope you’ll never have to).

Of course, experienced software testers are sometimes required to use screen shots and video capturing tools to recreate the defect. Interestingly, not all of the Toyota “bugs” have been reproducible, including one highly publicized incident. This makes accurate defect reporting even more important to developers and engineers, who must address the root cause of the issue as quickly as possible.

So instead of trying to recreate that  floor mat issue you had on the way to the grocery store, we suggest that you simply file your complaint in a clear, concise and calm manner. That goes for software testers as well.

So what about bugs, as in software bugs?  More than just a lame rhyme, it turns out that bugs may have a negative effect on our brains as well – if you believe the Extended Mind hypothesis.  Stick with me here.

The Extended Mind hypothesis says that our minds are more than what is contained inside our skulls.  When we create or use tools, then we are effectively creating extensions of ourselves.  For example, that would mean that there’s no difference between remembering the capital of the state of Kentucky and looking it up on Wikipedia.  (Here’s a link to help you remember.)

A recent study suggests that there may be some validity to this, a fact discovered by creating a simple software bug and seeing how people respond.  From a recent article in Wired:

An empirical test of ideas proposed by Martin Heidegger shows the great German philosopher to be correct: Everyday tools really do become part of ourselves.

The findings come from a deceptively simple study of people using a computer mouse rigged to malfunction. The resulting disruption in attention wasn’t superficial. It seemingly extended to the very roots of cognition.

“The person and the various parts of their brain and the mouse and the monitor are so tightly intertwined that they’re just one thing,” said Anthony Chemero, a cognitive scientist at Franklin & Marshall College. “The tool isn’t separate from you. It’s part of you.”

While drugs may be a lot worse for our brains than bugs, bugs can still be annoying.  They add to our stress and prevent us from accomplishing tasks.  Think about how you felt the last time you couldn’t remember someone’s name or forgot your keys.  Then think about how that would feel if it happened every time you tried to accomplish an important task (SYSTEM ERROR).  Stress like that adds up over time, potentially leading to health problem that are both physical and mental.

Software testers, you are a valuable line of defense in keeping the world sane.  You keep our brains off of bugs, no question about it.

But I digress! So, this week in testing brings us an interesting heart device bug discovered March 12, 2008.

A team of computer security researchers were able to gain wireless access to a combination heart defibrillator and pacemaker. According to the New York Times,

[The researchers] were able to reprogram it to shut down and to deliver jolts of electricity that would potentially be fatal. The researchers said they had also been able to glean personal patient data by eavesdropping on signals from the tiny wireless radio embedded in the implant as a way to let doctors monitor and adjust it without surgery.

Full report and more after the bump!

The researchers also made it clear that there’s no imminent need to be afraid of heart hackers for the following reasons: the experiment was worth $30,000 of lab equipment; it included specialists from the University of Washington & the University of Mass; the heart device was placed two inches from the test gear; and no security breach (in millions of implants worldwide) has ever been reported.

While risks are currently low, is too little attention being paid to security in the growing number of medical implants with wireless capabilities? Have you heard about any updates regarding this debate?

Read the full report here.

The bug was discovered while Gafa was writing a software testing app:

“You can be the least privileged user on the system and still crash it,” Gafa said. “I believe it is very easy for Microsoft to sort it out. They just need to validate arguments passed to Windows APIs.” (source: SC Magazine)

Microsoft is currently aware of the defect and responded with this insight:

“Our initial assessment of the report is that malicious code would have to already be running or a user would have to be able to run a specially crafted application to cause the system to crash. In either case, the system has already been compromised or the user has rights to logon to the system.”

I’m curious to hear if anyone has other stories of old bugs causing new problems or vulnerabilities?

On February 11, 2007, during its very first overseas deployment to Okinawa, Japan, six F-22 Raptors flying from Hawaii experienced multiple computer crashes, including navigation, communication and fuel system crashes, when crossing the International Date Line.

The problem arose not from the time change, but from the change in longitude from W179.99 degrees to E180 which occurs on the International Date Line.

The bug could have been potentially fatal, but fortunately, the fighters were able to return to Hawaii using visual contact with their tankers, the aircrafts used for aerial refueling.

If the weather would have taken a turn for the worse causing visibility to be compromised, this would have had a much bleaker ending.

Serious bugs have been on my mind as of late. Among others, Toyota’s experimentation with embedded software isn’t going too well these days. So is any software or testing full-proof? Are we capable of ensuring safety as we increasingly rely on software in our day-to-day lives?

To add more fuel to the fire, today the company Sophos, which surveyed 500+ organizations, came out with a new report stating that in the past year:

• 57% of users report they have been spammed via social networking sites
• 36% of users claim they’ve been sent malware via social networking sites
• 72% of survey respondents think social networks are a danger for their companies (see Mashable article)

What’s the solution? Tina Fey, in her show “30 Rock,” recently spoofed social networks with her creation of “YouFace” (combo of Facebook & MySpace). Terms such as “finger-tagged,” “weirdsie,” and “pho-lo” (for photo and hello) had many ROFL. See video clip after the bump!

But let’s be serious for a moment. Are these sites glorified chat rooms (as Alec Baldwin would have us believe)? Or have they become so critical to communicating with the media, customers, partners, prospects and investors, that blocking them would be catastrophic to your business?

Although the former makes for a great show, I have to side with the latter. So, can we keep our community-centric apps without posing security threats to our companies?