You are here

When minor application quality issues become a headache for end-users it's time to fix them

public://pictures/areichertpropix.jpg
Amy Reichert, QA Engineer, RxMxUSA

Why fix defects that don't technically malfunction or cause harm but only annoy users? After all, users can be trained to work around non-critical application quality defects. So what if it takes another year to correct the problem? It's non-critical, even if it's incredibly annoying. End users and customers report thousands of highly annoying but non-critical defects during any given release.

Don't be tempted by these rationalizations.

[ Get up to speed on quality-driven development with TechBeacon's new guide. Plus: Download the World Quality Report 2019-20 for lessons from leading organizations. ]

Why bother?

Many defects reported by quality assurance (QA) and software testing professionals sit in defect queues for years before they're fixed. Many times, software development companies ignore the defect QA entered until a customer reports the problem. Why would you 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 fix work at least several months out. Annoying defects aren't critical enough to move up the priority list and get fixed sooner; however, the consequences of leaving extremely annoying bugs out in the software needs to be considered. The defects may not be critical, but they may cause significant damage to a business's reputation.

[ Get up to speed with TechBeacon's Guide to Software Test Automation. Plus: Get the Buyer’s Guide for Selecting Software Test Automation Tools ]

Consider the consequences

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 non-critical bugs look sloppy and unprofessional. Sloppy and unprofessional user interfaces don't gain customers.

Consider spelling errors, for example. A physician or nurse might pull up their EHR application, and every time they add an allergy or a medication, they see a popup message confirming the save. Within that message is a spelling error like "Do you wnta to continue to place the order for penicillian?" At first it may be amusing, but over time it makes the users think of the application as a rushed job. Worse still, it may lead them 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.

User interfaces that don't match customer workflows

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 habits. However, if it causes a physician to not use the application, or do all they can to fight against the application, it may be worth fixing. Consider working with a variety of users to get a sense of different workflow options.

Allow physicians 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.

Incorrect calculations

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. Unfortunately, that's not unique. 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. Using incorrect calculation results, the customers using the application to design home plans may have created plans for snow areas. This 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. 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. It's important to fix annoying defects, especially those that make the application and the business look bad.

[ Learn how to apply DevOps principles to succeed with your SAP modernization in TechBeacon's new guide. Plus: Get the SAP HANA migration white paper. ]