Test Approach_v1_0 draftx

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
.