1
Modular Specification DIRECT Test Approach
P
REPARED
B
Y
:
Modular Specification
DIRECT Secured
Transport
Test
Approach
Version 1.0
November 18,
2011
2
Modular Specification DIRECT Test Approach
Document Change History
Version
Date
Items Changed Since Previous
Version
Changed By
1.0
0
9
/
12
/2011
Initial Draft
Kiran Yanamadala
1.1
11
/1
7
/2011
Updated test strategy
Kiran Yanamadala
3
Modular Specification DIRECT Test Approach
Introduction
Th
is
document describes the test approach for the
M
odular
S
pecifications
DIRECT secured
Transport
. Specifically,
this document will inform
the user
of
the general
testing
process performed
on
Reference Implementation (
RI
)
DIRECT secured transport
.
I
t includes
the roles and
responsibilities for each aspect of this approach to ensure effective use of
Department of
Heal
th and
Human Services (HHS) Office of the National Coordinator (ONC)
for Health Information Technology
resources while
preserving
the integrity, independence, and vendor neutrality of the testing and
results.
The actors for the testing will be an initiat
or
RI
Simple Mail Transfer Protocol (
SMTP
)
client
and a
respond
er
RI
SMTP
client
.
RI testing will not include a
Health Information Organization (HIO).
Instead, RI will create mock messages to and from HIOs to simulate message exchanges between
those organizations
/Do
c
tors
office
.
These components send email securely between a RI DIRECT email server and other SMTP mail
servers.
The initiat
or
RI
SMTP client
takes the mock request,
validates the request message based
on the requirements
, and
forwards
it to the
respond
er
RI
SMTP client through
other
SMTP server
s
.
The responder RI Gateway
receives
, and
validates the response message based on the requ
irements.
In a real
-
world setting the
responding RI Gateway
would then
forward the response to the
requesting HIO.
This document specifies the approaches for testing key scenarios, the necessary Test
Environment/Bed, Test Strategies, Assumptions,
Constrain
ts
and
Exclusions
to conduct RI unit
testing.
The initiator RI SMTP client validate
s
the incoming request information and digital
certificates us
ing
the Secured Transport Module.
ONC Exchange Validation Lab and
National
Institute of Standards and Testing (
NIST
)
test tools
are
available for use by the RI Test
team
.
These
tools could minimize construction of additional test tools. In keeping with the Agile methodology,
additional test cases may be identified during test execution and added to ensure all requi
rements
are fully tested.
Objectives
The main objective of this testing effort is to verify the requirements of the
M
odular
S
pecifications
DIRECT secured Transport
allocated to
RI
code
release
s
are met by the delivered
code
.
The goal of the RI
T
est
T
eam is
to develop test cases
in order
to
unit
test the
RI code
against
the requirements
.
The
test approach will
also
verify th
at the Transport and Security Modules interface correctly
,
ensuring that
developers have created
a quality product that meets the goals
of
DIRECT
.
4
Modular Specification DIRECT Test Approach
Test Strategy
The strategy can be applied at high (‘acceptance’
–
these tests are the tests that the user or
representative of the user runs to accept the requirement or functionality under test) and low
(unit/component) levels of testing.
1.
Developers are more likely to do unit/component testing
2.
These tests can be used for regression purposes and help maintain stability with
such a high level of change.
3.
Automate the test cases to validate the
Extreme Definition (
XD
)
web services
through
Simp
le Object Access Protocol
(
SOAP
) User Interface (
UI
)
Test Driven Development also means that testing takes on a specification role. In the absence of
detailed requirements, the test cases define the required behavior of the system. Acceptance and
Unit tes
ts become key requirements/feature and design artifacts. Test cases by their nature are
specific and can add detail and reduce ambiguity in requirements.
The focus is going to be on customer usage over technical implementation and uncovering flaws
over con
firming completeness. Simplifying
the
test strategy into use of two predefined levels of
testing and bugs
are
addressed in the bug report.
The testing team also performs the non
-
functional
quality criteria such as reliability, usability, performance,
scalability, and memory usage.
The
System integration testing
is
perform
ed
between two
Health Information Syste
ms Programme
(
HISPS
)
by exchanging the messages with and without encrypted and digitally
sign
atures.
The
client functionality with automated acceptanc
e tests
drives
the web services through SOAP
User
Interface (
UI tool
)
.
The SOAP UI tool will perform the v
erification
of
XD messages between the two
HISPS.
Test Environment/Test Bed
The Direct Secure Transport core components will use DIRECT common components like logging
and utilities. The DIRECT software will use the open source software Apache James as the
Mail
Enterprise
Server, which
will support SMTP and
Post Office Protocol 3
(
POP3
)
mail transfer agent.
The DIRECT software will use Apache Tomcat as the Web Server.
Test Bed:
The
i
nitiator
RI Gateway
and
r
esponder
RI Gateway
must
be configured with the following tools
.
1.
Apache
Tomcat app
lication
server
2.
Eclipse
Integrated Development Environment (
IDE
)
(Optional)
3.
Apache James mail server
5
Modular Specification DIRECT Test Approach
4.
Apache
Maven (Optional)
5.
Extensible Markup Language
(
XML
)
Spy
6.
Sun Microsystems Java Development
Kit (
JDK
)
7.
Testing
f
older
s
tructure
The
i
nitiator
RI Gateway
and
r
esponder
RI Gateway
must be configured to communicate with the
following server based resources:
1.
Apache Subversion (
SVN
)
2.
Amazon Web Services (AWS) Elastic Cloud Computing (
EC2
)
Validation
Environment
3.
JIRA Bug Tracking tool
4.
Atlassian
Bamboo Continuous Integration
Assumptions, Constraints and Exclusions
The
RI testing
must include all REQUIRED attributes in each request.
RI
testing
must
validate the OPTIONAL elements
to
handle an
y elements an
initiator
may
include in
a message.
Tests will be developed and executed on
each
M
odular
S
pecification
.
T
he Continuous Integration tool will execute unit tests.
Testing will validat
e
the
secured
Transport
component.
Bug Reporting
All issues noted during the testing effort will be posted in the JIRA
issue
-
tracking
tool
.
The
procedures for reco
r
ding bugs can be found
on the RI Wiki site
. The procedures for analyzing and
resolving the issue are also documented on the RI Wiki site.
Ea
ch
Build
of RI
Modular
S
pecification
and Testing
P
ilot
will follow these processes and
procedures to ensure that each issue is addressed in a consistent manner. Information pertaining to
problem reporting and resolution is included in the release
-
specific
validation plans.
Test Traceability Matrix
A traceability matrix of the requirements to the test cases is contained within
the
RI Transport
and Security
Test Scenarios and Cases
document
.
Each test case also
include
s
the
test step
s
for the
regression tests
t
hat are planned for each build
.
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο