Over a decade ago I graduated from Salisbury University, and went on to interview at Purdue Farms.
Yes,
Perdue Farms, run by Frank Perdue. They sell chicken and turkey, and lots of it.
During the interview, one item kept coming up, again and again: The assembly line.
Every day -- every minute of every day -- Purdue Farms has a conveyor belt that is pulling chicken in a line. Several of them. At end of the line, the chicken is wrapped, weighed, and a label is printed on it's end that is attached to the package. That label includes the weight and a bar-code. On the other end of the transaction, the grocery store can scan the label, get the weight, and calculate the price. (Nowadays, that label might include the shipping information.)
After packaging, the chickens are stacked, organized, put into the warehouse, frozen or delivered.
So if the conveyor belt goes down for anything more than about five seconds, you lose money. Not just a little money either; it's something like tens of thousands of dollars an hour. Lose the plant, and you are talking about hundreds of thousands of dollars an hour.
Which means if your software crashes once, you burn through your annual salary pretty quick.
Now this was a long time ago; I can't remember the exact numbers but they seemed to very high to me, and the importance and severity of having software that was 'good enough' was made very plain to me.
Switching gear a bit ... that whole Purdue Farms story reminds me of Software as a Service (SaaS).
You may remember when Software As a Service First came out. There were ads on television, pointing out that if all you need is a taxi to get from one place to another, you wouldn't buy a car. Yet what we typically buy software and never consider renting it.
A few companies, like Oracle and the ERP vendors, had some success 'renting' software early on -- at least, they'd charge a large up-front fee to buy the software, but also large annual fees for automatic upgrades and support. You may also recall that Microsoft wanted to do something like this for it's operating systems and office tools, and the entire market said 'no thanks.'
I'm not convinced that renting the operating system makes any sense, but one thing that the web gave us is internet-delivered web-based applications with nothing to install. In a web-delivered model, the supplying company needs to have servers up, technicians on salary, and even pay for bandwidth on an on-going basis.
So it makes sense to 'rent' a subscription to software that is delivered over the web. The typical split seems to be that business applications can charge a monthly fee (basecamp, quickbooks, Socialtext), while applications designed for an individual person (facebook, myspace) need to be free and supported by advertisements. Software in the middle, like, say, Google Docs or linkedin, which might be used by a recruiter or by an individual person, typically offer a 'freemium' model, where an individual person can use the application for free, but certain business uses -- like unsolicited invites, or the ability to send recruiting ads to a large group -- cost a fee.
Quickbooks is a great example. They hook you in with a basic service - invoicing and bookkeeping - that is free until you have twenty customers. After that, it's $9.99 a month. For someone running a micro-business, Quickbooks is absolutely wonderful. For larger businesses, they offer payroll, credit-card processing, and other business services. Here's a real business enabler, at an annual cost about as much as two months of your cell phone bill.
Now that is software as a service!
Right up until they go down.
Speaking of which,
intuit.quickbooks.com is down
right now. How do I know? I needed to login to create an invoice and I could not generate it.
Which means my tiny little freelance business is dead in the water.
That's no big deal for me I don't count it on it as my daily bread. But some people do, and a quick search of "is the quickbooks website down" finds that (A)
This ain't the first time it's happened, and (B) Entire businesses can be brought down by this.
If what your business does is accounting or bookkeeping, or reliant on sales on a daily basis, having QuickBooks go down isn't a big thing - it's the only thing. It is altogether too much like having the label printer go down at Purdue farms. That applies for any core business function that is outsourced, but most executives 'get' that; at least it appears on the radar. SaaS -- not so much.
Hopefully, at this point, I'm preaching to the choir. Some of you know that I work at Socialtext, a company that provides Collaboration software in a SaaS-y model. What do I think we, as testers, can do about this?
Well, a lot. If we work at SaaS vendors we can get involved in testing upgrades, obviously, but also in backup and restore of the data. We can get involved in downgrades of the server if the process is botched, or what does it take to patch the server. We can look at the architecture for possible defects, including the load balancer, 'heartbeat' like programs that monitor servers for uptime. We can start talking about redundancy and systems, and what if our datacenter loses it's web connection -- or electricity.
Or maybe you work in an IT shop, on the customer side. In that case, testers can get involved in the contracting process, looking for risks and ways to manage risk. What uptime does the vendor promise at what cost? Does that sound reasonable? Has the vendor kept it's promises? What has gone wrong at other companies on similar projects?
These are testing questons; they are investigation questions. We, as testers, know how to ask them.
SasS, and the cloud, are the new new thing, but then again, there is nothing new under the sun. Using a new technology is going to have risks, and we, as testers, can explore and mitigate risks. If your company is using cloud technologies or deploying SaaS, someone is going to define a testing role in the mix.
Let's get out there first and define it ourselves.