Ebola and Software Quality Assurance

Posted by Sappho on October 3rd, 2014 filed in Computers, Health and Medicine, News and Commentary

Every so often, a story I was already following suddenly reveals an angle that actually relates to my area of professional expertise. So it is now with Ebola. The Los Angeles Times reports on the Dallas hospital’s mistake in initially sending the new US Ebola patient home from the ER,

Hospital officials now blame a technical flaw for the failure to relay the information about Duncan’s background to the doctors. In a statement, the hospital said an electronic records glitch between the nurse who questioned Duncan and the doctor who treated him led to the lapse. The nurse noted in Duncan’s electronic chart that he said he had arrived from Africa. But the information was not transferred to the doctor’s electronic medical notes. Officials say they are now using a new process to record and share patient information.

I can’t speak to any other adjustments that may need to be made to hospital processes, to make sure any new Ebola cases don’t slip through the cracks, but electronic records are something I understand. In particular, testing software is something I can understand. Here is how errors like the one described slip in to software systems, and what needs to be done to catch them before software goes live.

A failure to transfer critical information from the nurse’s area of the electronic record to the doctor’s can be a bug that was introduced when writing the requirements (the requirement telling the programmers which information needed to be visible to the doctor was improperly written), in the software design (the requirement was there, but it was missed when designed the software), or in the coding phase. Whenever it was introduced, this is what needs to happen for the bug to be caught in the testing phase:

1. A thorough inventory of test cases. This should include testing every type of information you can enter in the system, and, if you have multiple roles (in this case, nurse and doctor), it should include the right test cases to cover how the doctor and nurse roles interact. One way that you miss this kind of thing in testing is that no one thought to test the case where the nurse enters travel information and the doctor checks for it in the chart.
2. All test cases need to be executed at least once, of course, but they also need to be executed again if a change has been made that might break that part of the code. Another way that you miss this kind of thing is when it worked once and then got broken. This part can be tricky, since there’s a limit to how often you can test everything. Things that can help: Automation of basic regression, communication between development and QA (so you know when a change has been made that might break something that you’ll need to retest), prioritizing the most critical tests (so that if you miss a bug, at least you can hope it won’t be the one that will lead to a patient with Ebola getting released), and allowing sufficient time to test the release build (slip in lots of changes at the end and skimp on time for testing and you may have trouble).
3. Test cases are generally written based on the design and requirement documents. But testers should also use their heads, and, if they see that the design and requirements documents missed an issue, flag the issue. If the nurse’s notes for travel aren’t visible to the doctor, and that behavior is consistent with the design and requirement documents, but you notice that this isn’t likely to be what’s actually useful, you’re being a good tested if you point the problem out.

Obviously, the more complex the system, and the more pressed for time people are when developing and testing it, the easier it is to miss these things. But you can see how important it is to learn best practices for not missing these errors.