4 ways minor bugs can lead to real business problems
Why fix defects that don't technically malfunction or cause harm but only annoy users? After all, users can be trained to work around noncritical application quality defects.
That argument continues like this: So what if it takes another year to correct the problem? It's noncritical, even if it's incredibly annoying. Right? Besides, end users and customers report thousands of highly annoying but noncritical defects during any given release.
Don't be tempted by these rationalizations. Here I’ll describe four ways in which seemingly minor bugs can lead to customer dissatisfaction and potentially a loss of revenue for your business. And I’ll suggest ways to address "little" problems before they become big ones.
Why QA teams need to sweat the small stuff
Many defects reported by quality assurance (QA) and software testing professionals sit in defect queues for years before they're fixed, and often, software development companies ignore the defect that QA entered until a customer reports the problem. Why would a company do that? The whole point of software testing is to find and report defects before they get released to the customer.
In fairness, most development teams are booked solid with feature and defect fixes at least several months out. Defects that are simply annoying aren't considered critical enough to move up the priority list and get fixed sooner. However, the consequences of leaving extremely annoying bugs in the software needs to be considered. The defects may not be critical, but they could cause significant damage to a business's reputation.
Here are the four ways that significant damage can ensue.
1. You get slammed on social media
This is not a minor problem. Annoyed customers use online venues to rate vendor software application quality and vent about bugs they're forced to work around. Online venues with negative comments about your software application are simply not good for business. Customers talk, and they discuss software applications before they even contact a sales resource.
Applications with even noncritical bugs look sloppy and unprofessional. Sloppy and unprofessional user interfaces don't gain customers.
2. Minor errors suggest bigger problems underneath
Consider a noncritical error, such as a spelling mistake or two in the UI. Imagine a physician or nurse who pulls up her EHR application, and every time she adds an allergy or a medication, she sees a popup message confirming the save. Within that message are spelling errors such as "Do you wnta to continue to place the order for penicillian?"
At first, it may be amusing, but over time it makes the user think of the application as a rushed job. Worse still, and naturally, it may lead her to question the quality of the application's other components. If the application's creators can't spell, can we trust them with complex calculations used to create medication dosages or financial investment calculations? I'd have my doubts. Sloppy, annoying errors cost you the trust and respect of your customers.
3. A UI that doesn't match the workflow reduces productivity
Software application design must consider the end-user workflow. No one wants to spend extra time working around an application—it creates duplicate work and reduces end-user productivity. If applications produced for physicians don't follow their normal workflow, they force users to change their processes.
Now, there are situations where it can be a good thing to change user habits. However, if it causes a physician to not use the application or to always fight against it, it may be worth fixing. Here are several ways you can improve this:
- Consider working with a variety of users to get a sense of different workflow options.
- Make it possible for users to configure the application to fit their own workflow, or the application's adoption rate will remain low and cause user dissatisfaction.
- Design the application to be flexible so physicians can customize it to their current use. Forcing users to work around the application isn't a recipe for long-term success.
- Be prepared to test configuration to verify it truly works prior to release. Don't give users another reason to hate the application.
4. Incorrect calculations cost time and money
I once had a development manager close a defect I'd found and tell me it wasn't a problem until a customer found it. While most QA professional would find that disrespectful, the attitude is not unique to my circumstances. This happens nearly every day somewhere in software development.
This particular case was worse than most. I'd found a defect in a financial application calculation that was ten cents off for each transaction. But it was deemed not big enough to fix, even though we had several customers who performed millions of sales transactions a year. Ten cents over several million transactions is a significant sum, one that resulted in inaccuracies in the customers' accounting records.
In another instance, in a home-design application, I reported a defect in the calculation the application performed for measuring snow loads. With incorrect calculation results, using the application to design housing in heavy snow regions could result in someone's roof collapsing. My defect was closed because the calculation still worked to "code." As long as it met most building codes, the fact that it was wrong didn't seem to matter. I still disagree.
Defects in calculations are unacceptable and annoying. Customers with millions of transactions will spend significant time fixing their accounting records, or re-reporting accounting figures. In my case, engineers double-checking their roof designs will need to duplicate work by manually performing the calculation. Worse than spelling errors but harder to spot, calculation errors make the design look shoddy and create distrust and frustration among end users.
Work to fix every bug before your customers find them
It's important to fix annoying defects, especially those that make the application and the business look bad. Here are a couple of things to consider.
If you are a QA professional working in a culture that diminishes the “little” problems you uncover, talk to your sales team about anecdotal comments they’ve heard from customers. Has buggy software been reported, ever, as a problem? By cataloging any such discontent in the customer base, you help affirm the reason for your job, and you’ve got hard evidence for fixing the next “little” bug you find.
Search the social media sites where your company’s software may be referenced. If all your reviews are glowing and positive, you may not win any arguments with management. On the other hand, even one reference to an annoying bug can cause potential customers in a competitive marketplace to think about giving your competition a chance.