Dear Students,

Here is some guidance on conducting the project that we at BSC have provided for Dr. Mathur’s testing course:

Introduction

We have provided an automated test station, loaded with the software that normally runs on it. One of the major software systems on the test station is called Medusa. Medusa is a C++ framework that comprises the backbone of our test station. It provides an interface between automated tests and the test station hardware. It supports test execution and reporting. It is the essential software infrastructure of the test station. Upgrading Medusa will be your project task.

General

Doctors communicate with our implantable pacemakers and defibrillators (PGs, or Pulse Generators) via telemetry, using a device known as a Programmer-Recorder-Monitor (PRM). The PRM is basically a PC with integrated touch screen and panel controls. The PRM runs a different GUI application for each family of PG that it communicates with Each PRM application is comprised of a number of screens and dialogs that allow the doctor to monitor and control the PG.

The purpose of our test station is to verify the operation of the GUI applications running on the PRM. Therefore, each test station also includes a PRM and a PG that communicate with each other via telemetry wand. The test station takes the place of the doctor, operating the PRM and monitoring communications between the PRM and the PG. For your project, you will be modifying and verifying how Medusa operates while it runs the automated tests that verify the GUI applications on the PRM.

Medusa does not operate in isolation. It always works in conjunction with an automated test. Therefore we have included two automated test suite baselines along with Medusa on the test station. Each baseline is comprised of a suite of automated software tests that verify a particular PRM GUI application. In this case we have sent the Insignia test baseline and the Vitality AVT test baseline. You will need to execute Insignia tests or Vitality AVT tests in order to see Medusa operate. The test station is initially configured with the Vitality AVT baseline active. Most Medusa issues we need addressed can be accomplished with the Vitality AVT baseline, so we suggest you use that most of the time. Only Issue #x requires use of the Insignia baseline. Instructions for switching between the baselines have been included (see C:/StudentProject/Instructions).

We have also sent an Insignia device (pacemaker) and a Vitality AVT device (defibrillator). The PRM has been loaded with both the Insignia and Vitality AVT GUI applications. So for example, for your Vitality AVT test runs, you will be running a Vitality AVT test, on the station, to verify the Vitality AVT PRM application on the PRM, as it communicates with the Vitality AVT PG. Likewise, for the Insignia test runs.

You may have to modify tests in order to get Medusa to exercise the functions you want to see. However, your project is primarily to update Medusa source files.

In addition to Medusa and the automated tests, there is also a layer of software classes in the test station that test projects use in common. So when you execute a test, you will be using the following software layers:

a)Medusa API

b)Common classes

c)Product-specific automated tests (Insignia or Vitality AVT) and product-specific supporting classes

Figure 1 illustrates the test station software structure. Item c, above, refers to the areas drawn within the dotted lines in the figure. Another point to mention, is that there is a separate Common software block for each project, though the figure shows it as one block.

There is also an Oracle database (called the Medusa database), with which the tests interact. Normally this communication happens over a network, but since that is not possible at Purdue, we have installed it directly onto the test station. There is a schema for Insignia and one for Vitality AVT. You will not need to modify this database to fix/enhance Medusa, but you may have to configure the ODBC drivers to connect the right database when you switch between test suite baselines. See C:/StudentProject/Instructions for how to do this.

Configuration Control

We are unable to export a software version control system to Purdue. However, it is vital that we are able to determine later, which software modifications relate to specific issues. We suggest therefore that you download a free version control system from the internet, such as CVS (see Using the version control system, you can check in revisions of Medusa source files as you modify them. Just be careful to not combine the edits made for different issues into the same file revision. We also suggest that you maintain a spreadsheet detailing all the Medusa file revisions you modify for each issue.

The Student Project

For this project, a list of Medusa issues (i.e. problems, complaints, requests) have been assembled (see the Medusa Issues List.doc at C:/StudentProject/Instructions). They have been screened for benefit to BSC, as well as feasibility for the students, remote from BSC, to resolve. Some of them are “confidence builders,” some are difficult, and one or two are probably “stretch goals.” The goal of the project is to resolve as many as your instructor and yourselves deem advisable for your course.

You are also asked to determine how to test these changes, in a manner consistent with the current Medusa validation procedure. The validation procedure is provided (Medusa System Test Protocol.doc at C:/StudentProject/MedusaDocs/Validation), and you are asked to update it (in MS-Word, set “Track Changes – Highlight Changes” on). The updated procedure will be evaluated at BSC by test engineers, and used to formally validate the next revision of Medusa. Note: The validation procedure calls for testing Medusa against three different BSC PGs and PRM GUI applications. The procedure often calls out scripts that are executed to validate various functions. It is not practical for you to attempt to replicate these environments, so we are not requesting that you write test scripts to validate your changes. Simply write manual test steps that an operator could follow to validate your changes. In case it is helpful, we have included scripts that were used during the last Medusa validation. These are stored in Zip archives along with the test protocol in C:/StudentProject/MedusaDocs/Validation.

Your project output sent back to BSC will then consist of,

a)Software edits to Medusa files

b)An updated Medusa validation procedure

c)Conceptual explanations of your approach to each issue. This should be an MS-Word or text document containing,

  1. an description of the problem and an analysis of what needs to be done and why
  2. a list of the file revisions made to Medusa to solve the problem (or you can reference a spreadsheet where the revisions are listed)

Here is a general procedure to follow:

For each issue in the Medusa Issues List,

  1. Analyze the issue and design an approach/strategy to resolving it
  2. Document a conceptual, rather than software-level explanation of your strategy. This will later be used by BSC test engineers in conjunction with your software changes to understand your approach to each problem.
  3. Make your software edits and test Medusa for the changes.
  4. Update the Medusa Validation procedure with the updates necessary to test the corrections/enhancements to Medusa

Security

The agreement between Purdue and BSC stipulates that the test station be housed in a secure area, accessible only to authorized staff and students. Also, that the password protection be used, and that the test station not be connected to any other computer or network.

Training

  1. The first week of class we suggest you familiarize yourselves with the test station and attempt to run the “About” test. Instructions for running this test are stored on the test station at C:/StudentProject/Instructions. Save most of your questions for the second week of class (see item 2, below). Urgent questions can be emailed to BSC (see item 4, below).
  2. The second week of class, a BSC test engineer (Craig Abrahamson) will be at Purdue for 2 days to answer your questions and make sure you are getting off to a good start.
  3. Medusa documents are stored on the test station at C:/StudentProject/MedusaDocs. We suggest you view the PowerPoint presentation on Medusa first, followed by “The Authoritative Guide to Medusa.doc”. These documents are probably not perfectly up-to-date, so the actual Medusa code should be your reference point. Use these documents to get the concepts of Medusa, not necessarily all the exact details.
  4. Your point of contact for questions will be Marc Loos, , 1-651-582-7443. He will probably direct you to other people for most questions. Non-urgent questions the first week of class should be held until the second week when an on-site engineer will be available for a couple of days.
  5. We have tried to come up with enough instructions to get you going. They can be found at C:/StudentProject/Instructions.