Assumptions: The Bane of Quality

Here in the United States, we have a saying that starts, “When you assume….”  Although it’s true, it’s more to our point to say, “When you assume, you make bad software.”

You see, assumptions are by definition unspoken, undocumented, and too frequently just plain different from one person to another, such as from business analyst to developer.  One will assume one thing, the other will assume something different, and the difference only comes to light some thousands or millions of dollars of development later.

Two cases in point:

VAT Cut Implications for Ecommerce Sites in the UK

In todays [sic] pre-budget report the Chancellor introduced a reduction in VAT rate from 17.5% to 15% to help kick start the economy and increase consumer spending.

VAT has been set at 17.5% since before ecommerce was invented and this latest change is going to cause a huge headache for ecommerce websites.

Some systems are likely to have VAT hard coded into the ecommerce systems but even advanced programs will still need to be adjusted to reflect the new rates.

Hard coding a tax rate?  How optimistic is that?  Well, maybe not so much optimism as expediency, and by “expediency,” I mean “willing to cut corners foolishly to maximize profit or at least minimize the loss on an underbid development project.”  (Thanks to PhilK for the link.)

Myth: Every system has Internet access

I work and live in rural Texas. Software purveyers are providing MISSION CRITICAL software which REQUIRES access to the Internet for some functionality. I did a field (literally, in a field) call on a system which works perfectly near the Interstate 35 corridor, but fails within two hours when further west. The problem? It tries to contact its host system to upload log files via the Internet and, because there is no telephone line attached (or even within a few miles), no WiFi and there are “no bars” for the cellular telephone card, it posts an error dialog and STOPS WORKING! Of course, this little “feature” or “requirement” does not appear in the documentation.

This reminds me of my days testing client/server applications. What if the client can’t reach the server? I’d ask.  That will never happen, the lead developer would say.  I’d send him a snarky remark in reply, but then the e-mail would go down and he wouldn’t get it.

Sometimes, these “oversights” do not even fall under an assumption; they fall under a that won’t happen or that will happen so infrequently that we’re not going to worry about it sort of reasoning.  But in many cases, it’s an assumption that the developer makes because nobody piped up and said otherwise.

That’s why, QA bretheren, you need to stick your head into those requirements discussions and make sure that you get everything, everything, spelled out.  Developers allowed to assume are developers allowed to improvise jazz riffs in the middle of your company’s symphony.  Okay, that metaphor oversells it, but that’s what you’ve got to do.

Because nobody else is going to do it.  They’ve all got Second Life characters to clothe, you know.

Comments are closed.

wordpress visitors