Software Testing Blog

This month’s installment of ‘This Week In Testing‘ takes us waaaay back to 1962 when the Mariner I space probe, America’s first planetary flyby that was supposed to go to Venus, went completely off course and had to be immediately destroyed — a mere 293 seconds after launch.

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?

In this month’s installment of This Week In Testing, the date was May 1996 and the setting was the First National Bank of Chicago (insert dramatic pause here). The gist? Software “glitches” caused the bank accounts of 823 customers of the major US bank to be credited with a total of $924,844,208.32 each.

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?

Fifteen years ago, Microsoft introduced one of their most perplexing products – Microsoft Bob.  Today Bob is known mostly as a product failure, but in 1995 it was hailed as the future of PC user interface design.  Released a few months before Windows 95 (which really was the future of PC user interface design), Bob was an audacious alternate interface built for Windows 3.1 that visualized programs on a computer as things found inside a home.

While Bob now looks like a bizarre alternate reality for UI design, in 1995 Microsoft designed Bob to help novice computer users better understand how to use their computer.  Perhaps the best known elements from Bob were the ever-present cartoon character “guides.”  Bob’s interface was primarily wizard driven, and the cartoon guides made the wizard process friendly and inviting. Check out this Youtube video to see a typical Bob session from a user point of view.

Bob flopped not long after it was launched for a number of reasons, including the fact that it was quickly overshadowed by Windows 95.  But Microsoft persevered and kept around the idea of animated guides.  We still celebrate Bob’s offspring: Clippy from Microsoft Office and Rover from Windows XP.  Oh wait, I mean the opposite of celebrate…denigrate.  Yeah, Bob’s memory is now pretty tarnished, but I think that’s short-sighted.

Today I come to truly celebrate Bob.  Keep reading for five things Microsoft Bob got right.

Read more…

Before I get into the story of this fascinating bug, I wanted to take a moment to introduce you to T.W.I.T. We liked the “bug-iversary” concept so much here at uTest that we decided to make it a recurring column, called T.W.I.T. or This Week In Testing (also noting the happy coincidence that the word “twit” is synonymous with “fool” and “dope,” words that characterize many of these bug follies ).

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!

Read more…

SCMagazine reported this week that researchers in Malta have discovered a decade-old vulnerability, present in all versions of Windows since 2000.  This bug can cause PCs to crash instantaneously and without warning, as well as reeling the compromised machine into a distributed denial-of-service (DDoS) attack.  This exploit is only dangerous if the user is duped into running an app with the malicious code (according to Paul Gafa, CTO of 2X Software).

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?

With our testing community currently hammering away in the “Bug Battle of the TV Networks” this week, it’s time to take a moment to reflect on our February bug-iversary.

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.

Read more…

Bug-iversary Alert! Tomorrow is the 20-year anniversary of the “crash” of the AT&T Long Distance Network. On January 15, 1990 faulty software was installed on the AT&T Electronic Switching System (Number 4 ESS): a one-line bug incapacitated the entire system, disabling switches throughout half the network.

Known as one of the most serious telecom bugs in history, more than 75 million calls were not connected during 9 hours, an estimated $60 million loss.

Dennis Burke of California Polytechnic said it best: “The Jan. 1990 incident showed how bugs in self-healing software can bring down healthy systems, and the difficulty of detecting obscure load- and time-dependent defects in software.”

Speaking of “load defects,” AT&T — after signing up to be exclusive U.S. provider of iPhone service — has recently come under fire for the quality of its network coverage. Businessweek’s top headlines read:

• An AT&T Mystery: Abrupt New York iPhone Shutdown
• AT&T Mulls Plans to Deal with iPhone Data Demand
• Can AT&T Meet iPhone Network Demands?

In light of this bug-iversary, I can’t help but wonder if more testing should have been done before AT&T took on the massive data demands of modern 3G smartphones? What do you think?