Computers: Benefit or Burden

Computers should be tools. That’s why they were built in the first place. They should enable the user to do more, in less time, and focus on their needs. For this to be possible, the user must be able to capitalize on the promises that their purchased software has made.

For many of us, this is the case often enough to get by. But I will bet that every single person who reads this page has had at least one issue with software that did not live up to its billing.

Macs and PCs can be very enabling devices, but they can also be the perceived source of much that is wrong with the world. Ok, maybe that’s a little over the top, but you know what I mean.

To be a useful tool, they must run software that makes a user’s life easier. Today’s software purports to meet most any need under the sun; it can do your takes, help you lose weight, match you up with your soul mate…just about anything they can make a pill for, you can also find software will “fix”.

To be fair, many software programs are actually able to do what they claim, just don’t ask the consuming public to figure out how to make it work. All too often, the most brilliant upgrades in functionality are lost to the world, not to be rediscovered for several years.

Why? How could such amazing software features not take the world by storm? That’s easy: Because they are hidden behind a morass of confusing instructions, incomprehensible UI, and user paths that no user in their right mind would ever think to try.

Software that is released in this state should embarrass the company that created it. Often the blame is shared between design, development, and QA; no one link in the chain can create this kind of problem. To shortchange the consumer this badly, it takes a real team effort.

The design is either too unwieldy or the documentation for the design lacks clarity or is incomplete. Thus when the development team begins its work, they either implement user paths that they should openly question or they create confusing user paths because the documentation is lacking – again, this should be questioned and not accepted by the dev team.

The QA team should have gotten involved prior to the development of such a piece of software, but sometimes they do not assert themselves into the process early enough. When it’s time for testing the software, the QA team should never let a confusing GUI or poorly designed software to ship.

That’s their job. Of the many responsibilities of a video game or commercial software tester is to advocate for the customer. If brilliant functionality and innovative features are hidden so deeply within the interface that the user will never see them, then they may as well not even exist. Your home PC or Mac cannot unearth the hidden code and present it to a user themselves…they need help. This help is easily given with just a few easy steps.

The design team needs to simplify. I can say that almost without thinking about it. I have seen countless computer software programs over the years, both in development and on the shelves, which would be valuable if only they were simple enough for the consumer to use.

Simplify. Have you ever fired up a piece of software and as you were using it just went, “Wow…why didn’t someone think of this sooner. This is a brilliant. Easy to use, elegant, and just simple. Why isn’t more software made this way?”

Too many designers, developers, and testers get so caught up in the coolness of their new technology that they lose sight of why they are developing it. Yes, the end goal is often to make money, but in order to make money, someone has to buy your product. If your offering is a burden and not a benefit, you will end up making less money.

Once the development team begins creating the software, they need to be sure that they understand exactly what they are creating. There should be no confusion as to what the end functionality will be. They often run into enough issues figuring out how to create the expected functionality – they don’t need any confusion about what it is supposed to be.

If there is any confusion, Dev should immediately get with Design and QA to gain consensus and clarity. To avoid this step is just asking for trouble.

When QA looks at the documentation, a real SQA professional should be able to identify the design and potential development challenges that will confuse the end-user. These issues should be brought to light at the earliest opportunity – preferably before development begins.

If the software reaches QA in such a state that it cannot possibly fulfill its promise to the consumer, any computer software testing team member worth their salt will begin squawking and screaming until the entire team understands that what they are creating is not acceptable. Unfortunately this is often not the case.

Either QA gets involved “too late” to make any of the necessary design changes or the QA team lacks the respect necessary to affect meaningful change. Or, worst of all, QA does not perform the testing necessary to identify that the consumer will have any problems. These are not acceptable situations.

Some very simple fixes:
• QA should be involved during the design phase – this is the least expensive time to fix a bug
• QA should be professional, accurate, and expert – thus respect is not a question
• Along will all other testing, QA needs to ensure they employ a holistic approach in their testing

This last point is a key area of Quality Assurance testing of computers and software that has become forgotten or overlooked. Concentrating so much on feature-specific functionality, many QA teams have forgone the needed End-to-End testing which ensures consumer’s computers will be able to deliver on the software’s promise.

It is a shame that more companies don’t seem to grasp the cost of delivering less-than-excellent computer software. Superior software that is easy for the consumer to use may seem expensive to develop properly, but what of the immense cost savings gained from fewer customer calls and thus less tech support. Unless your tech support team consists of a recorded message that just says, “R-T-F-M” your company is probably wasting quite a bit of money every quarter on support teams. Money that could be more productively spent developing better software and becoming a leader in the market.

It takes just a few very simple steps to adjust most dysfunctional development processes. Proper adjustment enables a company to produce better software, less expensively, that enhances their brand, and bolsters the company’s offerings long-term.

Does your company deliver superior software? Are the computers that run your software being unfairly tortured?

Strive for excellence, not perfection.
~H. Jackson Brown Jr.

Return from Computers: Benefit or Burden to Successful Quality Assurance Home