Challenges Faced while Testing in Healthcare domain

 

Testing has always been challenging in the software development life cycle of a product irrespective of any area of domain. Testing Healthcare products requires more of domain knowledge and testing in general is very critical in the life cycle stage of any software development activity.

Healthcare products pose much more challenges for its complexity in design, development and testing, impact on patient data, diagnosis results, and safety characteristics than compared to other domain products. On the other hand, Healthcare products has to comply for Safety and Regulatory standards and implement i.e, DICOM, HL7, IHE, HIPAA standards which makes good business sense to be in market competing with the other vendors. This in turn makes the test engineers face with multiple challenges while testing the healthcare software and delivering to the customer with high quality.

Some of the challenges faced while testing in the Healthcare domain are listed below.

Id

Challenge

Explanation

1

Domain and System Knowledge

Lack of domain and system knowledge will result in inadequacy of testing. Test engineers with testing knowledge will not only suffice testing the product as a whole but also must know the complete functionality, clinical usage scenarios, workflows, environment, standards used, configurations, regulations, interoperability, domain tools etc.

2

Clinical usage/ Workflow

Testers must have good understanding of clinical usage and workflow use cases of the product as used by the end users at clinical sites. Bugs raised on invalid use cases may be rejected which leads to waste of effort in finding and reporting the bugs.

3

Clinical Test data/ datasets

Lack of availability of standard test data/datasets during testing will lead to insufficient test coverage. Test engineers must have standard datasets classified based on various parameters stored at a shared central repository and make it available for testing to ensure adequate coverage of tests at various test levels.

4

Healthcare domain standards

Insufficient knowledge of domain standards will result in poor quality of testing. Test engineers must be trained and well equipped with standards (DICOM, HIPAA, IHE, HL7 etc..) while testing the product for interoperability, connectivity and security aspects.

5

Safety and Hazards

Healthcare softwares are designed around safety and hazard reqmts. Inadequate testing for safety and hazards will have a fatal impact on the product, end user and patient. Test engineers must have a good understanding & knowledge in identifying the safety and hazard tests and its impact.

6

Specialization tests i.e., Image quality, Performance, Reliability, interoperability, Concurrency, Hardware etc.,

Healthcare products have to be tested for some specific specialized tests to meet the quality goals of the product. Test engineers must be experienced, fully trained and possess special skills to perform these tests.

7

Process Compliance - FDA, ISO, CMMI

Healthcare devices are compliance to certain standards to certify that they are fit for intended use. Test engineers must be trained on these standards to perform their job well in qualifying the product during testing.

8

Exposure to end users/Application specialists and Site/Clinical visits.

Lack of exposure to end user use cases, interactions with Application specialists and non-awareness of clinical sites will result in insufficient knowledge of product and poor quality of tests.

9

Test Environment, Installation and Setup.

Unplanned test infrastructure and environment will affect the testing of software and delay the test execution cycle. Structured and Automated install process will reduce the lead-time in install of softwares in test systems.

10

No proper Ramp up/Training plan.

Adhoc or unstructured ramp up on the product will lead to poor quality of testing. A ramp up/training plan in place will help test engineers to gain good understanding on the product.

11

Non-Reproducible defects

Many a times tester comes across bugs by coincidence/random/exploratory testing which appear on specific configurations and are non-reproducible. Testing is extremely tedious and time consuming, as many times there would be random hangs in product. We cannot pin-point on where the issue is. This becomes difficulty in reproducing the bugs to developers.

12

Tedious manual verification

Lot of time is involved in install and setup. Interpretation of results output needs visual validation. For example the image display on a review workstation or the printed image from a printer. This led to an engineer specific interpretation of results. An engineer may have to do this on wide range of datasets. Repetitive work de-motivates test engineers many times.

13

Cross dependency of software

The software is complex with many different layers and components. Changes in one part of software can often cause breaks in other parts of the software. Hence whenever there is a change there is a need to ensure that there are no side effects and the product needs to be validated for stability. Test engineers should get the information before hand on the changes incorporated in the software before testing.

14

Unstable releases

Developers check in software and test team is made responsible for building the software and verifying it. Developers did not do sufficient unit testing before checking in. The code checked in was also not reviewed in many cases. Test engineers were unable to proceed on testing as per their plan as they faced many issues, which should have typically been caught during reviews and unit testing.

15

Crashing of testing schedules

Testing was taken up as last activity in project life cycle. There was a committed end date to customer. Any slippage in other phases of the project directly reduced time for testing. Many defects found during testing further reduced uninterrupted testing time.

16

Test Systems inadequacy. No dedicated hardware for test team.

Many times testing time is affected because of no dedicated test systems given to test team and testing on multiple projects gets assigned. Test engineers were forced to work at odd hours/weekends as the limited resources were in control of the development project manager and test engineers are given a lower priority during allocation of resources.

17

Underestimating testing efforts in project efforts

Testing team’s inputs were not taken during scoping phase. Testing teams efforts were typically underestimated. This leads to lower quality of testing as sufficient efforts could not be put in for the same.

18

Testware management

Lack of Testware mgmt process becomes tedious and time consuming in fetching and tracking project test docs for reuse and reference.

19

No documentation accompanying transfer to test team

There was no proper documentation accompanying releases to the test team. The test engineer was not aware of the Known Issues, Main Features to be tested, etc. Hence a lot of effort was wasted.

21

No involvement of test team in entire life cycle

Test engineers were involved late in the life cycle. This limited their contribution only to black box testing. Due to coming in late test engineers could not understand all the requirements of the product.

22

Cyclical nature of work

There would be phases during the project in which there would be hardly any work for the test engineers. This would specially be the case if the project manager has opted not to use the services of the test team for the unit as well as integration testing phases. At other times just before the release the same engineer would be overloaded and would be forced to work many late hours.

23

Low motivation of testing personnel

Many engineers are not willing to stick to the career in the area of healthcare domain testing. They feared a lack of growth and learning opportunities. Many engineers associated testing with non -creative and monotonous work.

24

Lack of experienced Healthcare domain testers

Many test engineers acquire skills in Healthcare domain testing and tend to switch over than making their career in the Healthcare domain. Test engineers must have willingness, dedication and passion towards the Healthcare domain. Experienced domain test engineers will be able to contribute much more in the quality of the product.

Views: 5176

Comment

You need to be a member of Test Republic to add comments!

Join Test Republic

Comment by shains on June 13, 2012 at 12:11am

I agree with Adarsh.. visiting customer sites/hospitals and talking to end users/clinical project managers helps a lot to understand clinical processes. 

Comment by Adarsh on June 12, 2012 at 11:54pm

Some of the ways:

Talk to Business analysts/Domain Experts/Application specialists

Web also gives much info

Read journals, clinical materials

Go for Hospital visit and talk to end users.

Refer Requirement docs, User manuals

Comment by Tester Srini on June 12, 2012 at 11:20pm

Adarsh,

Quite an interesting read. Would like to request you if you could help me out on the ways to acquire the clinical workflows. I am in the process of building up the knowledge base of our team.

Pls. advise.

Comment by shains on February 8, 2012 at 3:56am

Thank you very much for this. Extremely useful. 

© 2014   Created by Test Republic.

Badges  |  Report an Issue  |  Terms of Service