CIO —
Three years ago, Station Casinos came up with a great promotion to lure customers: $25 worth of free slot play on their electronic loyalty cards. It worked like a charm too. Gamblers flocked to the casino in droves.
That should have been a good thing.
But one Friday night, shortly after the promotion began, when players inserted their cards into the slot machines, nothing happened. The sheer number of people trying to access the machines—at the same time the accounting department was running a number of financial applications—caused the servers that stored all the promotional information to freeze. Irate, players threw their loyalty cards on the floor and raised a ruckus.
That was a bad thing.
The source of the problem? Testing. Marshall Andrew, Station Casinos’ VP of information technology and CIO, says Station Casinos never anticipated such an overwhelming response to the promotion. Consequently, IT did not test the system for such large volumes of activity, and certainly not while other programs were running. Station lost the cash they would have made that Friday, alienated customers and had to run another campaign to apologize; the casino invited some customers to return another weekend for $50 worth of free slots.
The moral: Testing is essential to developing high-quality software and to ensuring smooth business operations. It can’t be given short shrift; the consequences are too dire. Businesses—and, in some cases, lives—are at risk when a company fails to adequately and effectively test software for bugs and performance issues, or to determine whether the software meets business requirements or end users’ needs. (See "The High Cost of Flawed Testing" on Page 66.)
"The important thing when you roll out a system is to make sure it works," says Andrew, who has made significant changes to his testing organization (known as quality assurance, or QA) since then. First, he changed the testing process itself. Previously, developers had a great deal of freedom to change code while it was being tested to keep the project moving. Now, there are tight controls on the developers’ access to test code. To keep everyone honest, Andrew had the QA specialists begin reporting to the business analyst group rather than to the development group, whose work it was evaluating. Next, he hired more QA specialists—with business training—and involved them in the development process earlier, when business analysts are creating requirements documents, so that they can then develop test scripts based on business specifications right from the beginning.
