Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to QA test like your life depended on it

Amy Reichert QA Engineer, RxMxUSA

We all face health risks, and few of us will get through life without at least one visit to a doctor's office or the emergency room. Of all the risks out there, you probably don't think of application quality as being a huge concern to your health. But patients can be seriously affected when software errors arise in healthcare applications. That's why QA on these apps really can be a matter of life and death.

Quality assurance testing is usually prioritized by the risks it presents to the customer. In the case of many healthcare apps, the customer is not the patient, it's the person or entity that purchased the software and is uses it: the physicians, nurses, and other medical staff who serve the patient. So you need to think beyond the actual app user to who else an app failure might affect—in this case, the patients being treated by medical staff.

What does this mean for you and your non-healthcare app? Well, failures in your software may not have fatal consequences, but you should be just as thorough in your QA. Here are some of the common problems I face in my job every day as a software quality professional in healthcare, and how you can use my experience to find and fix critical defects in your own projects.

Verifying calculations

One problem area for healthcare apps is the many embedded calculations used to produce dosing amounts on patient medication orders. Medication doses differ among children, infants, and adults, and the application generates them by using complex, customer-configurable equations. I've often seen these calculations ignored in testing because of the complexity. If dosing calculations are incorrect, a pediatric patient could receive an adult dose that could be lethal.

Calculation and conversion logic is indeed complex, and it requires focused testing efforts. The consequences of failure in your own software may be different, but as a quality assurance tester you should always make the testing of calculations and unit conversions a priority.

Testing for workflow gaps

These are points in the application workflow that allow an action when it should be restricted. For example, I've seen an application allow users to place medication orders (prescriptions) for patients who had already been discharged. What happens to those prescription medications, and who pays for them? Failures like this can cost your organization money—or worse. Workflow gaps can also include openings that allow illegal activities to pass as valid actions, encouraging medical insurance fraud and prescription drug theft.

Think about how workflow gaps in your own critical applications could affect the business, and make sure you test for them. For example, if you're testing medication order entry or e-prescribing systems, verify that the security includes controls that prevent users from placing orders in illogical situations, such as when the patient is no longer in your care.

Verifying alerts that restrict actions

One of the worst defects I've ever found in a healthcare application went unnoticed for three years before it was fixed. Located in a tracking system, the defect made it possible, under certain circumstances, to place a severe allergy alert on a patient but still order and administer the drug that caused the allergic reaction, bypassing the allergy medication alert warning. I brought up the defect each time my organization brought in a new product manager, but because the sequence of events that lead to the problem was uncommon, nothing was done. Ultimately, I did manage to convince management to fix it so we could avoid having it happen at a customer site.

Many healthcare applications also include alerts on dosage amounts based on the patient's height and weight. In such cases, it's important to verify that users can't bypass those types of alerts. When testing, try seemingly obvious options. For example, try closing the alert window by clicking on the "X" control in the upper right corner of the window, as you would to close a browser window. I am constantly surprised by how often it works when it shouldn't. Users should never be able to bypass a dosage or allergy alert that is configured in the application. Alerts are critical to protecting patients and caregivers from medical mistakes. Your own users deserve no less.

Scrutinizing visual displays

Finally, always check the display for accuracy. It's easy in the midst of testing to glance over the display without truly reading it. Focus on the accuracy of the display because that's what your users, including doctors and other medical staff, use to care for their customers: the patients. In any industry, you need to think not only about your users but also about the impact on your users' customers.

For medical applications, you need to verify that the medications, dosages, units, and data are exactly as entered and remain that way between application sessions. It's also vital to check for data corruption, as well as hard-to-read text or images that might cause confusion. The clearer and more concise the data on the display the better. Unfortunately, this is often not the case. In fact, clinicians will tell you that some applications seem designed to make reading the display as difficult as possible for users working in high-stress environments, such as an emergency room or operating room.

Finally, reduce fancy fonts and use a font size people can read. Reduce dark background colors and field clumping—randomly organized arrays of data-entry fields that are either hard to read or don't follow a logical workflow entry sequence.

I learned these tips from the school of hard knocks. They're vital in healthcare, but every software quality assurance professional should take heed, particularly if you work with mission critical software. No matter what your industry, following these steps can help you and your business avoid costly unintended consequences.

Keep learning

Read more articles about: App Dev & TestingTesting