Is Software Testing a Lost Art?

‍“You can’t test quality into a product but proper testing can assure that a product has quality.” - John McMahon

Is it just me, or have you noticed many software applications, including websites, have “bugs”? 

Even the websites of large and well-known companies will sometimes take you to the never-never land of the 400’s (400 Bad Request, 401 Unauthorized, 402 Payment Required, 403 Forbidden, 404 Not Found - the most common error code on the internet). 

Website errors – the ones reflected by HTTP error codes, specifically, occur for several reasons. 

Human errors could lead visitors to encounter 404 errors and non-existent pages. However, the most likely cause is that someone, somewhere didn’t do sufficient testing of changes or additions to the website. A lack of consistent and complete testing before release is commonplace and found on many LIS laboratory information system websites, the pathology lab software most commonly used by medical labs.

Learn More: Why Integrated LIS System and Lab RCM Software is a Catalyst for Growth

So, what does this mean to a laboratory user of LIS system or lab revenue cycle management (lab RCM, laboratory billing) software? 

The proper functioning of your medical LIS and lab RCM is critical to the accuracy and safety of your lab’s operations. As a user or buyer of the LIS system and lab RCM products, it is incumbent on you to ensure that your lab vendors incorporate best practices for software testing.

Several stages of testing should be completed before a software program is cleared for use. They include: 

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing. 

Unit Testing: This focuses on specific units or components of the software to determine whether each is fully functional. The main aim of this endeavor is to determine whether the application functions as designed.

Integration Testing: This combines all of the units within a program and tests them as a group in a sequence to replicate the real-world business requirements. This stage is designed to find interface defects between the module's software functions.

System Testing: This is when the complete application or system is tested. The goal at this level is to evaluate whether the system has complied with all of the outlined requirements and to see that it meets quality standards. System testing should be undertaken by independent testers who haven’t been involved in developing the programs being tested.

Acceptance Testing: This determines whether the system is ready for release. The user will test the system to see whether the application meets their business needs. Once this process has been completed and the software has passed acceptance testing, the program can be delivered (to the production environment).

What’s listed above is not a complete list. While it covers the software development of new applications, it doesn’t address what happens when changes are made to already operating applications like laboratory information systems. When “improvements” or “fixes” are made to functioning LIS systems, these improvements can go badly. What is missing is a major cause of undiscovered LIS software “bugs.”

Regression Testing: This testing is performed to determine whether the recently made updates and changes to the LIS software have caused new defects in the existing laboratory information system functions.  Regression testing is a type of testing in the software development cycle that runs after every change to ensure that the update doesn’t introduce new unintended breaks. 

Regression testing addresses a common issue all developers face - the emergence of old (or new) “bugs” with new code.  It can ensure that a software application works as intended after any code changes, updates, revisions, improvements, or optimizations.

Have you ever taken your car to the mechanic with problems and the mechanic says ‘I’ve fixed the problem’? Then you drive away and the problem still exists. 

Why? 

Because the mechanic found A problem and looked no further to see if what was found was the cause or whether there were other problems, as well…. or whether the “fix” created a new problem.

What can you do as a laboratorian to help ensure that your medical LIS and lab RCM/lab billing system continues to function properly? 

Start by confirming that your lab vendors (LIS company and lab revenue cycle management partner) adhere to good manufacturing and testing processes.

Do a quick internet search and you’ll find several excellent website references that describe laboratory software testing best practices. 

You can also continue reading to find out how LigoLab, a leading developer of pathology software for medical laboratories, leaves no stone unturned while ensuring that its software solutions are properly tested before release. 

Check out LigoLab’s detailed methods for software development and testing and then compare what you learn with your existing software supplier or lab vendors under evaluation for partnership.

Editorial Note: To learn more about Dennis and his consulting services, visit his website at dwinsten.com.

LigoLab’s LIS Software Testing and Quality Control Plan 

It started in 2006 and ever since LigoLab has been blazing a new trail, setting the standard for how laboratory information system companies should develop their pathology lab software and create true partnerships with customers.

Known widely for its innovative all-in-one lab information system and laboratory billing software and its rapid development of features and enhancements that simplify laboratory workflow management, the LIS company is a master of digitally transforming clinical labs and pathology groups into modern and profitable businesses. 

Rapid development and stringent software testing protocols go hand-in-hand with LigoLab.

“It’s important to cover all the bases,” said Gor Kalantaryan, LigoLab’s Chief Operating Officer. “We can be as thorough and fast as possible because our process is automated and not limited to human capabilities.” 

The 5 Keys to LIS Software Development Quality Control 

The LigoLab Development team follows five quality control protocols that help ensure successful LIS software releases. They are as follows:

Development Code Audits: The team conducts separate code reviews involving a senior developer and an architect. Both must agree and approve the development plan before integration starts.

Automated Regression QA (White Box Testing): LigoLab next initiates automated regression testing that runs on every build. This important step ensures that new developments won’t introduce or reintroduce underlying issues.

“This testing is code-based, behind-the-scenes, and entails using robotics to test the logic that drives the actual functionality of the application,” said Kalantaryan. “A virtual robot clicks application elements through the user interface (UI). The robot is coded and acts like a person sitting there doing the test, so there isn't any variation from one test to another. It's the same test every time.”

Kalantaryan also noted that robotic regression testing is valuable because it allows developers to catch UI artifacts that may have been missed with only pure code testing.

Manual QA (Black Box Testing): Manual QA is conducted by the Support team and a member of the QA department to ensure full coverage.

This testing involved a human who doesn't know what's happening behind the scenes. He or she is purely there for the user's experience,” explained Kalantaryan. “The tester receives a debriefing about the feature and its intended functionality, and then proceeds to test the feature to see what issues arise during use.”

Unlike automated regression QA, this type of testing isn’t consistent from one test to another and serves as the final layer of quality control. 

Version Control: LigoLab’s Development process includes version control over the LIS software. This optimizes change management and ensures precise changes are deployed. It also makes it easier for the Development team to track what may have caused an issue.

Agile Development Model: The Development process features biweekly bursts (sprints) and daily scrums to ensure proper turnaround for all development items.

LIS Software Testing and Customer Involvement

Kalantaryan continued by detailing the importance of customer involvement when testing LIS system software.

“We very much support customer testing and encourage them to test their workflows as much as possible before going live with a major update,” he said.

As part of its standard licensing agreement with customers, LigoLab provides and manages three dedicated LIS software environments: Testing, Training, and Production.

First, all new features are developed, validated, and automatically rolled out to all customers via their testing environment. Next, the training environment is there for the customers to train, test, and validate specifically controlled version updates. Only after thorough testing and validation, are version updates pushed to the production environment.

Editorial Note: For an in-depth rundown of LigoLab’s approach to customer support and training, CLICK HERE.  

No Room for LIS Software Shortcuts 

With LIS software testing, there’s no room for shortcuts.

That is and always has been the LigoLab way. 

Yes, LigoLab spends more time and resources on the development cycle than the norm, but the extra attention to detail ensures quality code, software, and scalability.

“Our philosophy benefits us and our customers by addressing issues promptly, preventing problems from worsening over time, thereby avoiding the need for more extensive resources later,” concluded Kalantaryan. 

Learn More: Stability and Performance: The Two Most Important Aspects of a Modern Laboratory Operation