Hardware Reference
In-Depth Information
a physiological process as it changes. The complexity and risk profile of med-
ical devices varies widely and range from a consumer digital thermometer for
minor diagnosis, and an implanted artificial heart that is critical to preserving
a patient's life, to a therapeutic X-ray machine with a computer user interface,
programmable software controlled therapy and anatomical and biophysical mod-
elling in the software, which is operated under a high level of professional staff
supervision [24]. Analysis of medical device recalls highlights the diverse nature
of medical device software failures. The FDA found that during 1983 - 1987 ap-
proximately 44% of the quality problems that led to voluntary recalls of medical
devices were attributed to errors or deficiencies designed into particular medical
devices rather than having been inserted during the manufacturing phase. The
study also recognised software quality management practices as a means to pre-
vent failure [25]. In the medical device industry, the software used to control a
device takes on an additional role - it must help ensure the safety of the user.
There are many challenges to implementing safe software. Software design needs
to include deliberate engineering practices and rigorous approaches for software
testing such as an expert customer defining suitable tests before development
begins.
3 Related Work
Many approaches to conducting acceptance testing exist. Some concentrate on
acting as a “recording device” allowing user actions to be replayed against a
system, checking for deviations. However, this approach is mainly limited to
Graphical User Interface (GUI) testing of a specific version of a system, using a
tool such as the Selenium IDE [26]. Tools for writing acceptance tests in a cus-
tomer friendly format and appropriate for continuous integration exist. RSpec,
for example, is a “Behaviour Driven Development framework for Ruby” [27].
It promotes a workflow that involves writing stories in a somewhat prescrip-
tive natural language style and then manually translating these steps into Ruby.
While the authors consider this approach interesting for new stories, it has lim-
itations in dealing with pre-existing documents. Other open source tools aimed
at supporting ATDD exist including EasyAccept which supports both tabular
and sequential styles [28].
Generally, the Framework for Integrated Tests (FIT) is the most widely ac-
cepted tool for managing acceptance tests in agile development and therefore
practising ATDD [29]. In FIT's simplest workflow a user, places inputs and
some expected output into a tabular format, a
ColumnFixture
[30]. The devel-
oper then writes code (
fixtures
) that executes this data against the system's
production code. Other built-in fixture included in FIT include
ActionFixtures
for testing a “sequence of commands” and
RowFixtures
for “comparing test
data to objects in the system” [30]. FitNesse is a Wiki framework developed to
support FIT [31]. It facilitates the editing of FIT tables in a browser allowing
non-programming experts to add content. While FIT tables can be written in
any tool that can export HTML, such as Microsoft Excel, these generic tools do
