| || |
Release of an FDA regulated product story
When I first came back to this forum, I was asked to talk about my experiences with working on "testing safety-critical software" and how this company has gone about doing that. Not sure if this is of interest to anyone but here's what has transpired in the almost 6 weeks I've been aboard. Hopefully this is what people were looking for when they asked me to write this down.
Current Project/Product Line: 1) hardware of a PDA monitor and sensor to record data to form endocardiograms. 2) software on both the sensor and monitor that stores data and then transmits that data via radio waves between them and then through phone lines (landline & cell) to present an actual ECG (EKG) chart that a physician can use to help him develop patterns for his patient's heart activity.
This product line release to Beta, I was told, is not following the "norm" in terms of process but there obviously stil needs to be loads of documentation. My manager has so much paperwork involved in why QA didn't finish all the testing of the "test protocols" which were written by a 3rd party originally. Instead QA (me and my team members) have spent the last few weeks generally testing in almost an ad hoc fashion while the 5th Alpha Test completed. Now of course, with the release due tomorrow, we're in a mad rush to finish up what we can (I'm running timing of warnings and alarm tests now). In doing so, we're using our bug tracking system to rerun the test protocols that failed in Alpha Test #4.
Test Protocols - as earlier mentioned, written by a 3rd party company in which I have no knowledge. These protocols though, are written as a series of steps to prove a few test cases and then logged as one protocol. Sections are as follows: Test Object/Specification(s) contain brief summary. Target Environment Information conatin Unit Under Test software labels (what are the build names), software configuration and hardware configuration. Test Setup specifying the equipment used by serial, model and ESN numbers. Setup Step all the setup steps including software versions that appear on the devices (different than labels mentioned earlier). Test Case Approach which gives one or two sentences about each test case involved in a particular protocol. Instructions/Expected Results section details exactly the steps of what the tester needs to execute and record for results at specific points within the test case. Acceptance (Pass/Fail) Criteria with Test Observations conclude a test case. Finally, at the bottom of this page contains the overall Pass or Fail checkboxes. Each page requires a signature and date. Appendix - Trace Matrix follows as the last page containing the test case numberand what verifications were done linking these verifications to the Software Requirement Spec number.
Some of these Test Protocols can go for more than 40 or 50 pages due to the number of steps involved to finish a test case. As we execute the test, we are required to check each and every step including setup.
After we complete the Test Protocol, we have to scan the document to create a PDF file which is then placed in our product lifecycle managemet software tool, Agile, which along with other documents, QA creates an "Engineering Change Order" or ECO document and right now, I am not responsble. However, am required to complete a Test Report document containing Purpose, References (Test Protocol doc # & SRS doc #) Summary of Test Results. Along with the Test Protocol, the Test Report, all log files (gathered from doing the Test Protocols) are all attached to create the ECO. Like I said, I don't know how to do that yet, but next go around, I'm sure I will. Everything goes into Agile and all revisions are tracked as each document does contain revision history.
Well, so far that is what I can share. Hope it's helpful.