# Has anyone used Ruby for validated FDA applications? **URL:** \ **Category:** ruby-talk\ **Created:** [3 May 2005 10:59 UTC](https://rubytalk.org/t/has-anyone-used-ruby-for-validated-fda-applications/18081 "2005-05-03T10:59:51Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Simon\_Crase](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@Simon\_Crase](https://rubytalk.org/u/Simon_Crase)\ **Post date:** [3 May 2005 10:59 UTC](https://rubytalk.org/t/has-anyone-used-ruby-for-validated-fda-applications/18081/1 "2005-05-03T10:59:51Z")
I'm considering using Ruby for a project for a medical application; the production code won't be written using Ruby, but I believe that Ruby will be a big help for writing test scripts, and also for checking the source code to ensure that it conforms to our guidelines, and that various tables, in our specification, have been transcribed correctly. At some point I can imagine an FDA auditor saying:"OK, your Ruby script says that the code conforms to your spec. What steps have you taken to validate your script?" Me "We tested with Ruby Unit" FDA Auditor "What steps did you take to validate Ruby Unit and the Ruby interpreter?" Any ideas on what to say next? Cheers, Simon ---
**Author:** ![Wayne\_Pierce](https://avatars.discourse-cdn.com/v4/letter/w/8c91f0/32.png) [@Wayne\_Pierce](https://rubytalk.org/u/Wayne_Pierce)\ **Post date:** [3 May 2005 12:11 UTC](https://rubytalk.org/t/has-anyone-used-ruby-for-validated-fda-applications/18081/2 "2005-05-03T12:11:48Z")
Take two different programs, with two different languages if you must, and run both against your program. This way you can compare the results. Most auditors just want some assurance that you have thoroughly tested and documented the environment. By having two different ways to get the same result you have a check and balance. Whether you want someone else to write the second check is entirely up to you and your level of paranoia. Wayne > **···** > > On 5/3/05, Simon Crase \ wrote: > > > I'm considering using Ruby for a project for a medical application; the > > production code won't be written using Ruby, but I believe that Ruby > > will be a big help for writing test scripts, and also for checking the > > source code to ensure that it conforms to our guidelines, and that > > various tables, in our specification, have been transcribed correctly. > > > > At some point I can imagine an FDA auditor saying:"OK, your Ruby script > > says that the code conforms to your spec. What steps have you taken to > > validate your script?" > > Me "We tested with Ruby Unit" > > > > FDA Auditor "What steps did you take to validate Ruby Unit and the Ruby > > interpreter?" > > > > Any ideas on what to say next? > > > > Cheers, > > > > Simon ---
**Author:** ![William\_Morgan](https://avatars.discourse-cdn.com/v4/letter/w/b77776/32.png) [@William\_Morgan](https://rubytalk.org/u/William_Morgan)\ **Post date:** [3 May 2005 12:27 UTC](https://rubytalk.org/t/has-anyone-used-ruby-for-validated-fda-applications/18081/3 "2005-05-03T12:27:10Z")
Excerpts from Simon Crase's mail of 3 May 2005 (EDT): > At some point I can imagine an FDA auditor saying:"OK, your Ruby script > says that the code conforms to your spec. What steps have you taken to > validate your script?" > Me "We tested with Ruby Unit" > > FDA Auditor "What steps did you take to validate Ruby Unit and the Ruby > interpreter?" > > Any ideas on what to say next? What would you normally say about your trust in a third-party tool? For commercial software I suppose you might say, "The company that created this tool assures us it's correct." For open source software like Test::Unit, I would say something like: a) Test::Unit has an active user and developer community, which we    monitor for bug reports, patches, other user's experiences, etc.    (i.e. "we read ruby-talk"); b) To the best of our knowledge there are no outstanding bugs that affect    its ability to evaluate our code; and c) [Depending how thorough you need to be] We've created an ad-hoc test    suite of buggy code that we believe is representative of the types of    errors potentially present in our code, and Test::Unit successfully    identifies them. > **···** > > -- > William \ ---
**Author:** ![Ira\_Burton](https://avatars.discourse-cdn.com/v4/letter/i/dec6dc/32.png) [@Ira\_Burton](https://rubytalk.org/u/Ira_Burton)\ **Post date:** [3 May 2005 13:50 UTC](https://rubytalk.org/t/has-anyone-used-ruby-for-validated-fda-applications/18081/4 "2005-05-03T13:50:10Z")
We have made similar arguments for our php based work and it has never resulted in any sort of negative action. We typically have a fairly bloated test suite that we run our code against. Auditors really like to see that sort of thing. They are not looking to have you prove that there are absolutely no bugs, but rather you have made a good faith effort to find them all. (This obviously depends to what degree a failure of your software can lead to a dangerous result for a patient.) > **···** > > On 5/3/05, William Morgan \ wrote: > > > Excerpts from Simon Crase's mail of 3 May 2005 (EDT): > > \> At some point I can imagine an FDA auditor saying:"OK, your Ruby script > > \> says that the code conforms to your spec. What steps have you taken to > > \> validate your script?" > > \> Me "We tested with Ruby Unit" > > \> > > \> FDA Auditor "What steps did you take to validate Ruby Unit and the Ruby > > \> interpreter?" > > \> > > \> Any ideas on what to say next? > > > > What would you normally say about your trust in a third-party tool? For > > commercial software I suppose you might say, "The company that created > > this tool assures us it's correct." For open source software like > > Test::Unit, I would say something like: > > > > a) Test::Unit has an active user and developer community, which we > >    monitor for bug reports, patches, other user's experiences, etc. > >    (i.e. "we read ruby-talk"); > > b) To the best of our knowledge there are no outstanding bugs that affect > >    its ability to evaluate our code; and > > c) [Depending how thorough you need to be] We've created an ad-hoc test > >    suite of buggy code that we believe is representative of the types of > >    errors potentially present in our code, and Test::Unit successfully > >    identifies them. > > > > -- > > William \