Quality Assurance for a Healthcare Client’s Project – How we did it

Requirements stated by the client

Our development team was tasked with merging the CRM system’s functionality used by offline clinics with an online healthcare platform preferred by the patients. To make it work, our team was supposed to implement certain compilations. As for other requirements — there were not many specifics mentioned, and we decided to take it from there based on our experience and see how it goes.

The platform needed various tests: reliability, accessibility, functionality, performance, and others. Long story short, all the bugs we spotted we had to report. The timing was a bit pressing, but we still paid attention to the exploring phase and test planning. With diligently made test case design, execution and reporting phases went as expected. Here is a bit more about how we managed our client’s healthcare project.

Defining of Long-Term Objectives

As a rule, we inquire about our clients’ long-term objectives, even if they don’t immediately discuss them with us. Those are usually not direct QA project requirements, but they are essential for our software quality assurance engineers. In this case, it was more than a good idea to ask about the project’s goals in advance. We have learned that it was supposed to become a pilot healthcare CRM system with a patient portal that the client would later scale up for many more facilities as a White Label SaaS solution. Understanding this goal allowed us to add some extra QA process steps and see the purposes of QA better in this case. 

Here is something to point out. It is impossible to develop a software solution for a complex multi-component architecture without an early quality assurance audit. If scalability is a priority, you need the assurance team involved as early as possible. From day one, a scalable solution with various simultaneous processes requires constant testing with multiple objectives.

Test-driven development is necessary for complex, scalable projects, and “develop first, test later” can only harm. If you do what’s right, you can rest assured that your healthcare project develops as expected and can work both on its own and as a part of a much larger system. If objectives of quality assurance are not met from the very beginning, or testing is not on the picture as a whole, architecture mistakes turn healthcare software solutions into a castle on the sand. Needless to say that any post-release testing, especially of cumbersome systems, is critically expensive and can through the whole project off the market. 

We had to face a few challenges as our team entered the project when the majority of the components were already developed. Due to this, our quality assurance specialists had to face some high-level architecture issues with the platform. We were lucky enough to work with a client whose priorities were clear and just right — quality over time to market. Together, we managed to alter the product as necessary and launch it (for more details, read further). Despite, in the end, it was a success, this experience was a loud reminder that quality assurance in healthcare should never be underestimated and start early. 

Project Course 

This project came with challenges, but its goal was not only commercial, it was also noble. Our client wanted to bring higher standards to online and offline healthcare across the US, and we were there to help realize this project safely. 

The QA Methodology we have chosen

At first, we offered the client’s development team (Atlanta, US) to cooperate via Scrum methodology. However, soon we realized that it was just not how our client’s team used to work, and we had to adjust effectively. We switched to a methodology that was similar to the well-known Waterfall one, with minor adjustments relevant to the industry.

Phase #1: Exploring (2 Months)

Product exploring is a critical stage among QA process steps, as it defines the entire course a team takes later. At this stage, a quality assurance specialist deeply examines the product and its supporting documentation and analyzes the client’s requirements before launching the testing sequence. We have assembled a team of five QA engineers and one QA lead for this project. Within two months, we ran more than five thousand checks. We have used the gathered results to create guidelines for further testing activities. In parallel with the exploring, we were working on creating a registry and dealing with missing descriptive documentation. 

Phase #2: Actual Testing (1.5 Months)

Our first step was to write test case scenarios to help us check the software’s web version (Chrome, Safari). At this phase, we had three members in play — three QA engineers, one of whom doubles as a Team Lead. Check on the testing  types we have performed:

Functional testing

Functional testing allows checking whether a system and its parts work as expected. Here is where our pre-defined checklists and guidelines came in handy. A feature-load of the CRM for the offline clinic was top high, so we concentrated our testing effort on its performance and effect on the in-house operations of the hospital. We wanted to determine if:

• Patient information is safe, but the clinic’s administrative and medical personnel can easily access it;
• Information on the platform gets real-time updates;
• All personnel related to a particular patient’s case receive timely notifications safely;
• A registered nurse entering the shift sees all the procedures that may require their presence;
• Prescription management is precise, and the chances that one patient gets prescribed another patient’s medication are as close to zero as technically possible;
• Only authorized requests can result in a person getting access to the health records;
• The receptionist’s personal account has needed fields and accesses to make specific doctor appointments;
• The doctor’s profile is user-friendly and has all the features for efficient and quick patient management. 

Bugs discovered were communicated straight to the development team with additional instructions on bug’s reproducing.  

Regression testing

Regression testing is on when all the mistakes detected during functional testing are fixed. Due to the complex architecture of medical software testing, reaching the overall purpose of QA, it is crucial to re-run all the test case scenarios. Once we were done checking all the system’s roles, making sure that they work as expected, we reviewed:

• Interoperability of different account roles;
• The scalability of the software system;
• The ability of the commercial product to work separately;
• The project data’s leakage-proof;
• Platform’s compliance with regulatory requirements and healthcare industry standards.

UI testing

UI and UX excellence were among our objectives of quality assurance. We needed to check how the software was built, how it looks, how satisfied the audience was with it, and whether the UX guides were met in general. We have explored the intuitiveness of the platform, whether people with various tech levels can use it easily, whether design corresponds with audience’s expectations and, importantly, whether the product is in compliance with the general healthcare software patterns.

What testing results were achieved

Three and a half months later, we reported more than 200 software mistakes in the products. Bugs we have reported varied from small UI inconsistencies to top-level errors that endangered the entire project’s operability. For instance, we discovered the core-driven unevenness in information distribution that made the entire system less reliable. After two release builds, we, and the clients’ team, were ready to launch a market-ready version of the tested software.