The Nuances of QA in Healthcare: Our Experience

by Anastasiia A. on Dec 9, 2021

Software testing and quality assurance for healthcare applications requires a unique approach. Along with testing an applications performance and UI, QA teams must also ensure that the software meets industry-specific quality standards.

What are the specifics of healthcare software testing? Theoretically speaking, these include extra attention to reliability and cybersecurity, compatibility with widely used medical hardware, and regulatory compliance among others. But in this post, we are aiming at answering this question through practice. Here’s our story about a healthcare software testing project we have successfully delivered to a US-based hospital — an operational platform & patient portal. 

Project Basics:

The software our team was testing is a multi-component digital solution that consists of a software system for a hospital and a patient portal for online remote consultations. It was developed for a US clinic in close collaboration with actual doctors and caregivers working at several healthcare facilities.

The system allows users to electronically perform the following functions:

  • For doctors: to manage their practice, including appointment scheduling, patient session management, receipts tracking and storage, internal and external communication (with patients and hospital personnel), and remote healthcare sessions handling;
  • For hospital staff: patient care & hospital operations management through personal profile having different functions depending on the role ― registered nurses, receptionists, physicians assistants, etc.
  • For patients: registration form fill-out, paid remote consultations with doctors, easy access to assigned prescriptions, and appointment scheduling available on the patient’s portal.
  • A separate division for prescription management and receipts storage.
Core features & capabilities of healthcare CRM

Client Requirements for Testing

We were informed that the main objective of the development team is to effectively merge the functionality of a CRM system for offline clinics with an online healthcare platform for patients. This implied certain complications in the solution’s architecture, which our team had to account for. Other than that, the client wasn’t too specific about their requirements for the testing process. 

The development team wanted the platform to be extensively checked for performance, reliability, accessibility, and functionality. Basically, we were asked to report back all the bugs we find regardless of their kind or place. So, we started the Quality Assurance process with the exploring phase, which later was to be followed by test planning, test case design, and execution with reporting and cycle closure.

Long-Term Objectives

Even though the client didn’t state that as a requirement for his QA project with us, we decided to discuss the long-term objectives they would like to achieve. During an interview with the client we discovered that the development of a healthcare CRM system with a patient portal for one particular hospital is supposed to be a pilot project which the client wants to scale up sell to other facilities as a White Label SaaS solution. This clear picture of the client’s end-goal helped us determine several extra steps our QA team would need to take.  

The truth is, the development of software solutions with a complex multi-component architecture is barely possible without a Quality Assurance team involved early, especially if scalability is a high priority for a product owner. A scalable solution that balances out multiple simultaneous processes and allows different positions to interact seamlessly inside one software system requires constant testing unit by unit since day one. 


“Scalability is not something you can achieve late in the game. It is either planned and tested at the very start of development or off the table once and for all.” 


Test-driven approach to software development implies that you come up with strict requirements first, and fulfill them with a functional code later, as opposed to the “develop first, test later” classic scheme. That way, you can be sure every structural part of your healthcare software system is capable of working both on its own and as a part of a large system. Otherwise, when the project gets tested after it’s been developed, architecture mistakes discovered late might turn a software solution into a house of cards. Needless to say, early testing is way more cost-effective than last-minute error fixes.

Our team entered the project when most of the system components were already developed. This made us facing a few challenges, like high-level architecture issues found in the platform. Luckily, the client-side team prioritized quality over time to market, so altogether we managed to polish the product to a reliable market-ready launch (which you can find described in detail below). However, despite the successful results we achieved, this experience reminded us once again: early testing should never be underestimated, especially with medical software systems.

Project Course 

Methodology

Initially, we offered the development team working on the client side (Atlanta, US) to organize our cooperation by Scrum methodology. However, on diving deeper into the project, we realized that this methodology simply does not match the way the client’s team is used to work. To keep our future collaboration productive, our testing team adjusted to the development team’s way of working, which for the most part, is similar to the Waterfall methodology with some slight amendments.

Quality Assurance Timeline for healthcare project software testing

Phase #1: Exploring (2 Months)

Product exploring is a crucial part of any QA project, as it defines the whole future course of it. During this phase, the testing team gets to deeply examine the digital product, its supporting documentation, and the client’s requirements for future testing. 

A team of five QA engineers, one QA Lead was assembled and we started analyzing the codebase. In about two months, we performed more than 5000 checks. The results gathered were used to create checklists ― guidelines for further quality assurance activities we planned. Also, simultaneously with exploring, we started working on the missing descriptive documentation for the project.

Phase #2: Actual Testing (1.5 Months)

We started with writing test case scenarios to check the web version of the software. Software testing environment included Chrome and Safari web browsers. During this phase, our team consisted of 3 members: two QA engineers and one Team Lead, who also took part in testing as another analyst. We performed the following testing types on the project:

Functional testing

Functional testing checks if a system and its separate components work as required. Our team executed functional tests manually and in accordance with pre-defined checklists written by the end of the exploring phase. Due to the high feature-load of the CRM for the offline clinic, most of our testing effort was targeted to its performance and impact on the hospital in-house operations. To put it briefly, test case scenarios we followed helped us to determine if:

  • Doctor’s personal profile is easy to navigate and has all the necessary features for quick patient management;
  • Patient information is highly accessible but stored safely;
  • Health records are distributed only upon authorized requests inside the platform;
  • All patient case personnel receives notifications timely;
  • Information on the platform is updated in real-time;
  • A core application element for prescription management works accurately and there’s no chance drug use information could be confused across patients;
  • Receptionist personal account allows relevant hospital workers to establish type-specific doctor appointments;
  • Registered nurse account receives schedule updates showing what medical services are planned during the shift that require his/her assistance.

These are the roughly listed functions we were focusing on when testing the functionality of the platform. Every bug we spotted was then described in a corresponding report we forwarded to the development team with instructions on how to reproduce a bug. In terms of the patient portal, we were mostly checking the functionality needed to run online consultations and transmit the information to the offline hospital about the upcoming appointments.


“The biggest discovery we (and our client) made is how much easier and cheaper it would be to implement necessary high-level changes if our QA team entered the project earlier.”


Regression testing

Regression testing is meant to check whether a digital product functions as required even after its codebase was changed due to bug fixes and new features implemented. This stage takes place after all the errors discovered during functional testing got fixed. As with medical software testing that usually has a quite complex architecture, it is very important to re-execute all the test case scenarios, sometimes even more than once, to assure all the structural components integrate with each other seamlessly.

During the regression testing, in addition to checking how the updated codebase is working, we started to analyze the scalability of the whole system. After we checked every system role separately and made sure that each of them works just right after some small fixes and functional updates, we finally got to high-level testing. That’s when we checked whether:

  • Different account roles ― doctor, nurse, receptionist ― interact smoothly with one another;
  • The software system can be scaled up if necessary;
  • The patient portal can work as a separate commercial product for hospitals across the United States;
  • The project is data leakage-proof;
  • The platform follows all the required regulations and healthcare industry standards.

UI testing

UI and UX testing is a process of checking the user interface of a software application ― how it was built, how it looks, what experience it gives to the audience, and whether it guides the users through the system as it was planned by developers. During this testing stage, we explored:

  • How intuitive the platform is in general;
  • Whether the platform is suitable for people of different tech skills levels;
  • Does the UI/UX design correspond equally well to client and beta testers expectations and correlate with modern digital design trends;
  • If the project adheres to the regular healthcare software patterns in terms of terminology, operations, and third-party integrations.
Healthcare software project Summary: QA & Testing

Testing Results Achieved

In about 3,5 months, we found about 200 software errors in the platform. The bugs reported were very diverse, from tiny UI inconsistencies to some serious high-level errors that can be potentially dangerous for the project’s future. For example, we discovered that the initially developed architecture does not work as planned with all the modules inside the system. This led to an uneven distribution of information across different patient care positions in the hospital making the whole system less reliable. By reporting that back to the development team, we raised a discussion about the need for significant changes in the platform, which was supported by the client. Overall, we delivered 2 release builds during the project and finally, achieved the market-ready version of the healthcare software solution that is now used in the offline clinic helping its staff to care for patients in the fastest and the most accurate way.