We use Selenium for our FDA validation testing.

For those not familiar with FDA and NASA quality control initiatives and testing requirements, suffice it to say that the federal government tends to talk in terms of 'validation and verification testing' in many of its' regulations. There's decades of history behind this term, and the three important takeaways are the following:

First, a project has to have two or more testing strategies, so as not to fall into a bias with a single testing strategy. Second, one of those testing strategies has to be user-centric, commonly known as validation testing. Examples include crash test dummies and end-to-end software acceptance tests. Third, most any other testing strategy can qualify as verification testing.

So, we use Selenium for our FDA validation testing, because it simulates a user walking through the software.

It's big and bloated and slow, and the legacy version runs on Java, and it's brittle and doubles the amount of code we have to write, and is otherwise a total pain in the ass. But it's like folding your parachute before skydiving or having a depth gauge when SCUBA diving or placing bolts when climbing a wall. There are simply some tasks that you don't want to do without safety gear.

And for all its' pain to use, Selenium is like safety gear for building your tech stack. We've migrated across a half a dozen user interfaces, two entirely different back-end languages, three or four data protocols, and countless utilities over the years. And Selenium warns us when we're in danger and it catches us when we fall.

We use Mocha for our FDA verification testing. It's integrated into Meteor, our upstream web application framework. We like how battle tested it is, its' syntax, its' options of reporters, and countless other features. Most everybody can agree on mocha, and that gets us half-way through our FDA verification and validation (V&V) testing strategy.

As bioinformaticists, we regularly get asked to develop apps or websites which are HIPAA compliant, connect to an EHR, or are ready for FDA regulation.

Regarding the last, the FDA has built up best practices over the past 40 or 50 years regarding "validation and verification" testing. Without going into a lengthy history of FDA regulations, suffice it to say that there are two important distinctions about validation and verification testing - the first of which is that there has to be more than one testing methodology, so that manufacturers or developers don't get a sort of biased tunnel vision; and the second is that at least one of the testing methodologies has to be user-centric. So, it's not enough to test the engine of a car, a manufacturer also must have crash test dummies.

In the world of software written for hospitals and clinical environments, we interpret the verification and validation testing requirements in terms of requiring more than one testing framework, one of which is an end-to-end testing harness using a technology like Selenium. It's not enough to have unit testing, but we also need e2e acceptance testing. Selenium has traditionally been the only game in town, and has been a struggle to work with at times. But it's a tank, and keeps on rolling. We particularly like recent incarnations using Chromedriver and WebDriver protocols, which is slowly reducing the reliance on the legacy Java server.