Hardware Reference
In-Depth Information
Automating Expert-Defined Tests: A Suitable
Approach for the Medical Device Industry?
David Connolly
1
, Fergal Mc Caffery
2
, and Frank Keenan
1
1
Software Technology Research Centre
2
Regulated Software Research Group,
Dundalk Institute of Technology, Dublin Road, Dundalk, Ireland
{
david.connolly,fergal.mccaffery,frank.keenan
}
@dkit.ie
Abstract.
Testing is frequently reported as a crucial stage in the soft-
ware development process. With traditional approaches acceptance test-
ing is the last stage of the process before release to customer. Acceptance
Test Driven Development (ATDD) promotes the role of an expert cus-
tomer in defining tests and uses tool support to automate and execute
these tests. Here the challenge is to support such an expert in the reuse
of existing documentation. This paper details an experiment in a generic
domain while outlining plans for development of an automated testing
model that could assist medical device companies to adhere to regulatory
guidelines by providing them with a fully traceable testing artifacts.
1
Introduction
A large part of software development expenditure is attributed to
testing
.Tradi-
tionally, with plan-driven development, acceptance testing, the process of testing
functional requirements with “data supplied by the customer” [1] occurs as the
final stage of the development process long after the initial investigation has
completed [2]. Many reports, however, highlight that costs can be reduced by
detecting errors earlier in development [3]. Also supporting this, in many do-
mains, such as the medical device industry, software is developed subject to a
regulatory environment with a tendency for extensive documentation. This reg-
ulatory environment features guidelines and standards such as [4] - [9]. Despite
many constraints already being specified, this is often ignored with tests written
from scratch after implementation is complete. In contrast, agile approaches re-
quire constant customer collaboration throughout development, with customer
provision of acceptance tests being an important part of this role. Often, it is
recommended that tests be identified before implementation commences. In eX-
treme Programming (XP) [10], for example, acceptance tests are defined as a
part of the User Stories practice and, as such, are written before coding of the
story begins. In this context, functional tests are synonymous with acceptance
tests [11]. Further, for accurate user stories, Cohn recommends customers them-
selves specify acceptance tests with developers and testers providing support as
required [12]. The XP practice of Continuous Integration, that is, building and
testing a system frequently, maximizes the use of the executable and automated
