Test Data Prep Cut From 4 Hours to 2, Coverage Up 12×: Automating a DNA Analysis LIMS

Sona Hakobyan

Author

Sona Hakobyan

Sona Hakobyan is a Senior Copywriter at PFLB. She writes and edits content for websites, blogs, and internal platforms. Sona participates in cross-functional content planning and production. Her experience includes work on international content teams and B2B communications.

Senior Copywriter

Reviewed by Boris Seleznev

Reviewed by

Boris Seleznev

Boris Seleznev is a seasoned performance engineer with over 10 years of experience in the field. Throughout his career, he has successfully delivered more than 200 load testing projects, both as an engineer and in managerial roles. Currently, Boris serves as the Professional Services Director at PFLB, where he leads a team of 150 skilled performance engineers.

Why a lab system cannot be tested casually

The client's priority was automatic examination of the LIMS that manages genetic blood analysis end to end - application filling, genetic material analysis, and delivery of results to a doctor. The assembly line nature of that analysis required meticulous testing, in accordance with United States Department of Health and Human Services requirements.

The arithmetic explains the problem better than any description of it. One rack holds 96 test tubes, four of which are controls. Each tube is examined by 30 variants of a single test. And preparing the test scenario for one tube manually took up to four hours, because the test data had to satisfy special conditions when combined - you cannot simply generate plausible values, they have to be internally consistent with each other. Multiply that out and the testing effort stops being a task and becomes a ceiling on how often the product can change.

Underneath the arithmetic sits the reason nobody was willing to just test less. The system must not be prone to errors, because any disinformation about a client's health can have serious consequences for that person and their relatives - and the company's reputation with it. This is a category of software where an undetected regression is not a support ticket.

What needed solving

• Automation of test data generation - removing the four-hour manual assembly per tube.
• Verification of the genetic analysis' life cycle - checking the process end to end, not just individual screens.
• Dependency examination for analysis parameters and results - confirming that inputs and outputs relate the way they are specified to.
• System's precision examination - confirming the results are right, not merely produced.

What was built

PFLB automated two things: test data creation, and testing for genetic blood analysis. The toolchain was deliberately plain - Selenium WebDriver as the automation testing tool, Java to write the autotests, and C# to run them.

Given how intensively the system is developed - updates every 2–3 weeks plus regular patches - the approach increased testing performance by a factor of 40. The autotests now run every night.

The automation caught real defects, in time to matter:

• Performance decrease after changes in system functionality and database structure.
• Errors in analysis results.
• Input analysis data that differed in the doctor's report - the most consequential class of bug in a system whose entire purpose is delivering a correct result to a clinician.

Results

• Test scenario preparation per tube: 4 hours → 2 hours.
• Test coverage: up by a factor of 12.
• Testing performance overall: up by a factor of 40.
• Autotests run nightly, against a codebase that changes every 2–3 weeks.
• A set of critical bugs at the level of genetic material research was eliminated.
• PFLB's automated testing reports served as supporting documents for the client's yearly US Department of Health and Human Services certification.

Questions this engagement answers

How do you automate test data when the data has to satisfy constraints?

You build a generator that understands the constraints rather than a script that fills fields. Here the test data had to satisfy special conditions during combination, which is exactly why the manual version took four hours a tube - and exactly why automating it halved the time while multiplying coverage twelvefold. That is the core of test data management.

What makes test automation pay for itself?

Change frequency. This client ships every 2–3 weeks with patches in between, so every release would otherwise have re-incurred the manual preparation cost. Automation is worth most where the same work repeats on a short cycle - and least where a system is tested once and frozen.

Does automated testing help with regulatory certification?

It did here. The client submitted PFLB's automated testing reports as supporting documents for annual certification by the US Department of Health and Human Services. Test evidence generated as a by-product of nightly runs is more defensible than evidence assembled for an audit, which is the practical argument for software validation built into the pipeline.

What kind of bugs does this catch that manual testing misses?

The ones that only appear across the whole life cycle: performance degradation after a database structure change, errors in analysis results, and input data that did not match what appeared in the doctor's report. None of those are visible in a single-screen check.