Quality Assurance is a Process, Not a Department

File this one under the “how-the-hell-have-we-not-blogged-about-this-yet” category. A few weeks ago, BATS Global Markets Inc. had just made its IPO debut. Seconds after trading began, a software bug “disrupted trading” of the stock (i.e. it went from $16 to under a penny in seconds), prompting the company to cancel its offering. You can read more about it here.

Anyway, the incident spurred Forbes writer Ken Goldstein to re-examine the meaning of quality assurance. There’s a lot of gold in this article, but here are a few of my favorite nuggets (emphasis added):

There is no argument that we live in a world of staggering speed, where competitors race to meet customer needs and time to market matters. Innovation is always factored by the ticking clock, who gets the jump and the competitive advantage, when a cost center becomes a profit center. Information compounds on our desktops, the team with analysis paralysis most often loses to the nimble risk takers–but all this means is that in product development, the role of Quality Assurance (QA) has never been more critical.

Notice that he does not say the QA department has never been more critical. He says the role of QA. This is an important distinction which he goes on to clarify:

Here is the way I like to think about quality in product development: Quality Assurance is a Process, not a Department….

…Of course every great development company will have a final step in the process called Quality Control or Quality Assurance, but it is my sense that the QA formal group is there to be the standard-bearer for Quality and rally the company around it, putting a final go or no-go procedure in place before the world gets its hands on a product, but not accepting proxy status for an otherwise poor process. A QA department is not a dumping ground, not a remote server where code is parked as a step function or convenient checkpoint in a perfunctory release approval, not a cynical target of blame. QA is the proxy for the customer, not management, and as such must have a voice that is shared throughout a company. If a Decision Maker chooses not to listen to either the process or a warning from fully objective and independent QA stewards, you get what you get.

Continue Reading

Essential Guide to Mobile App Testing
Essential Guide to Mobile App Testing

This Will Only Take a Second: United Nations Debates Time Change

In the software business, it’s all about precision, as even the slightest coding mistake can lead to catastrophic failure. This lesson is clearly not lost on the folks over at the United Nations telecommunications agency, who are meeting as we speak to decide whether or not to abolish the leap second. That’s right, the leap second.

The Sidney Morning Herald explains how this relates to software testing:

Unlike the better-known leap year, which adds a day to February in a familiar four-year cycle, the leap second is tacked on once every few years to synchronise atomic clocks – the world’s scientific timekeepers – with Earth’s rotational cycle, which, sadly, does not run quite like clockwork. The next one is scheduled for June 30 (do not bother to adjust your watch).

The United States is the primary proponent for doing away with the leap second, arguing that these sporadic adjustments, if botched or overlooked, could lead to major foul-ups if electronic systems that depend on the precise time – including computer and cellphone networks, air traffic control and financial trading markets – do not agree on the time.

Abolishing the leap second “removes one potential source of catastrophic failure for the world’s computer networks,” said Geoff Chester, a spokesman for the US Naval Observatory, America’s primary timekeeper. “That one second becomes a problem if you don’t take it into account.”

By now, you’re probably wondering what the “debate” is all about. Is anyone voting in favor of catastrophic failure? On the other hand, how can a unit of time be abolished, even if it’s only a second? The story continues:

Continue Reading

Essential Guide to Mobile App Testing

Missile Firing Predator Drones + Virus = Bad News

We recently wrote about the need for security testing on medical equipment, but it looks like an even larger virus threat has come to light – on U.S. Predator and Reaper drone weapons systems.

While an unofficial source said they suspect it’s benign, they also added, “But we just don’t know”.  The thought of an attack drone being hacked is a chilling to say the least.  Jalpnik has a nice write-up of some of their historic missions (and the virus) but this seems to reinforce the hypothesis that the United States is entering a “Code War”.

Here’s the crux:

The virus, first detected nearly two weeks ago by the military’s Host-Based Security System, has not prevented pilots at Creech Air Force Base in Nevada from flying their missions overseas. Nor have there been any confirmed incidents of classified information being lost or sent to an outside source. But the virus has resisted multiple efforts to remove it from Creech’s computers, network security specialists say. And the infection underscores the ongoing security risks in what has become the U.S. military’s most important weapons system.

We keep wiping it off, and it keeps coming back,” says a source familiar with the network infection, one of three that told Danger Room about the virus. “We think it’s benign. But we just don’t know.”

For those interested, we have a new whitepaper on Software Security Testing.

Essential Guide to Mobile App Testing

Code of Silence: When To Keep Your Software Bugs a Secret

Chances are, if your software bugs make it on the front page of The Consumerist, then you’ve probably done some highly questionable things — either in product design or execution. Last week it was Apple (i.e. Location-Gate). This week it’s USAA Bank.  Here’s a brief, firsthand summary of the ladder company’s unresolved issues:

Apparently their website is full of bugs, shows inaccurate ledger balances, shows debits as credits and vica-versa, and apparently just makes up balances. I was informed that they are aware of the bug and have been for several months, and that they have to fix all accounts effected manually. Worse, they have chosen not to notify anybody of the problem and they have chosen to continue using their new money manager software rather than rolling back to their previous software until this bug is fixed.

The representative told me that they expect to have this issues fixed by May 20th and it could be affecting anybody west of the central time zone. If USAA members are having trouble on their accounts, they will need to call and have their accounts added to the IT ticket # 4347297 to have them fixed.

Should USAA bank have notified its customers of a bug that renders their application useless? The answer here should be self-evident to all our faithful readers. But in other circumstances, the answer is not so cut and dry. That said, here are three instances when you should keep your software bugs a secret.

Continue Reading

Essential Guide to Mobile App Testing