The Nuances of QA in Healthcare: Our Experience

Anastasiia A. by Anastasiia A. on 12/7/2021

The Nuances of QA in Healthcare: Our Experience

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.

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:

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:

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:

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.

We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy