For all health care software applications, there are at least three critical concerns that software testers must
consider: patient safety, usability and end user satisfaction. But in business reality, it's almost impossible to thoroughly and continuously test the entire application.
So how do managers set testing priorities? It's important to strike a balance. Patient safety and data integrity are always imperative in health care applications, but usability matters, too. Is the software forcing users to change their expected workflow? Is it forcing them to spend time working around issues in the application? The test team's job is to produce software that health care providers can trust and use without interfering with existing workflow processes.
In the health care applications world, risk is the loss of business reputation based on released software that fails to function properly.
Risk analysis can help test teams achieve that goal by defining which areas of the application are most critical to test. This article explains why risk analysis is essential for health care applications. And it offers a simple method that will help improve application quality while also adhering to tight deadlines.
What is risk?
Risk is the possibility of a negative or undesirable effect. In the health care applications world, risk is the loss of business reputation based on released software that fails to function properly. Risk is releasing software with a defect that causes harm to a patient or to the financial health of the organization. Risk is usually negative, and it affects individuals, teams and the business organization as a whole in a noticeable way. After all, if the software release runs smoothly and functions with no perceived errors, all is quiet. But if customers find significant defects, the reputation of the company behind the software is tarnished.
Software test teams focus on the negative risks not only because these risks directly affect customers, but also because they affect the reputations of testers. Testers hate missing defects, and when defects occur in health care applications the implications can be serious. For example, data pertaining to a patient's peanut allergy must be correct and must be saved and passed between applications accurately. Failure to do so could be fatal.
How to perform risk analysis
At its most basic level, risk analysis is about communication. Each test team member schedules a meeting to review application functionality with the development team, business and/or technical analysts and product managers -- essentially all members of the software development team.
To prepare for the meeting, the test team creates a list of the functional areas of the application rated by risk. Say, for example, the application allows physicians to place medication orders on a patient. The application then communicates that information to the nursing user, along with administration schedules for each medication.
Using any tool the test team prefers -- spreadsheet, a document with tables or a white board -- the team lists the functional areas. Using the example above, the list may include:
- Order security
- Administration security
- Recording actions
- Medication administration
Even with this simple example, each area could logically be considered high risk. That is why communication among all team members is so important. It's up to the team to determine which functional areas of the application are more important than the others. The approach used to discuss the options should enable the team to combine the knowledge of the programmer, who knows where the code is most fragile, with the input of the product manager and analyst, who understand what your customers need; it should also recognize the opinions of the testers and members of the deployment team. Communicating and deciding as a team results in a well-rounded risk analysis.
Risk analysis is a valuable tool that gives your test team the ability to balance testing priorities. It's useful for any application type, but it's essential for health care applications where patient safety is job number one. Getting input from all members of the development team from coding to installation produces a balanced and more accurate risk assessment because risk is judged from all viewpoints.
Risk analysis helps the testing team set priorities. If the testing cycle is shortened, the team can focus the job on high-risk areas first, and even determine the number of tests you truly need for effective coverage.
This simple approach to risk analysis improves application quality by factoring input from both the technical and business professionals on the team. Granted, it may sound too simple, especially when compared with risk analysis methods that use complex, time-intensive studies or analytical tools. I'm not suggesting these tools or methods are not valuable. But they simply don't accommodate the speed and agility required when developing health care software applications in a business environment.