3. Software test environment

3.1. UW Tower server room

DIMS deployments are currently hosted in the University of Washington Tower (“UW Tower”) data center. Plans are in place to migrate hardware to another data center at Semaphore Corporation in Seattle.

Each deployed system will be separated from the others and operate independently (in terms of services and logical network topologies). Even if they are in the same rack and possibly sharing some fundamental resources (e.g., Network Attached Storage (NAS), or switched VLANs, they will each be deployed, configured, and will operate in such a manner as to be fully taken down without impacting the operation of the other environments.

This will allow development, test and evaluation, and user acceptance test

3.2. Software items

Software Items Table
Software item Purpose
Jira Ticketing, task tracking, etc.
Zephyr for Jira Test management plug-in for Jira
Robot Framework Open source Acceptance Test-Driven Development (ATTD) tool
Bats TAP-compliant testing framework for Bash
Custom DIMS scripts Serve specific custom test functions as needed.

3.3. Hardware and firmware items

Hardware Items Tables
Hardware Item Purpose
  • Dell PowerEdge R715 server
  • 128GB RAM
  • 2x12-Core 1.8GHz AMD Opteron processors
  • 12 x 1TB drives in RAID 5 array
Server capable of running all DIMS components in containers
  • Dell PowerEdge R720 server
  • 128GB RAM
  • 4x12-Core 2.40Ghz Intel Xeon E5-2695 v2
  • 6 x 4TB drives in RAID 5 array
Server capable of running all DIMS components in containers
  • Dell PowerEdge R510 server
  • 2 x 1TB drives
Compute cluster capable server

3.4. Proprietary nature, acquirer’s rights, and licensing

Some tests defined and anticipated under this plan involve use of a licensed Jira ticketing system using the Zephyr for Jira plug-in. These are primarily development-related tests that fall under the levels Unit, Integration, and/or Component Interface test levels, of type Expected Value and/or Desk check as defined in Section Test levels and Test classes, respectively.

The remainder of the tests will use open source products either acquired from their original source, or produced by the DIMS team and delivered with the final system. (See Section License for the license under which DIMS software is being released.)

3.5. Installation, testing, and control

Deployment tests will start with a bare-metal server with a network connection capable of routing to the internet. From there, the following general high-level steps will be performed:

  1. Operating system installation to the bare-metal server will be performed according to steps outlined in documentation. (This may be done using DHCP dynamically assigned addresses so as to minimize the number of manual steps required to install the base operating system.)
  2. Network level configuration of the operating system will be performed by manually entering the required attributes (e.g., the way Security Onion Setup Phase 1 is performed) into a software configuration database and/or configuration file.
  3. The software configuration database and/or configuration file will be applied to the system, configuring all DIMS components for initial use.
  4. Further manual steps will be necessary to provision initial user accounts in the portal and/or other DIMS system administration components.
  5. The system will be put into a “test” mode to perform system tests to validate that all DIMS components are up and running and the system is functional. Initial data input tests may be performed at this point to validate that input and output functions are working.

3.6. Participating organizations

Table Participants Roles lists participants, their roles and responsibilities, related to testing.

Participants Roles
Participants Roles and Responsibilities
DIMS development team
Primary persons involved in testing DIMS components at all test levels. Most will be on-site at the specified test locations, while some will be remote.
PRISEM participants
Involved in higher-level testing focused on user acceptance testing and bug identification, as their time and availability permit. May be on-site or remote.
Other stakeholders
Involved in higher-level testing focused on user acceptance testing and bug identification, as their time and availability permit. Most likely will be remote.

3.7. Orientation plan

People involved with testing will be provided with guidance in the form of user documentation, a copy of this test plan, and any specifics of how to perform the specified tests. This may include providing them with access to software described in Software items, or some other form of checklist that will enable them to know the tests to be performed, acceptance criteria, and a means of reporting test results.

3.8. Tests to be performed

Specific tests of test classes expected value testing and desk check testing (see Section Test classes) that are manual in nature, and are expected to be performed by stakeholders for the purpose of acceptance testing, will be documented and provided as part of orientation prior to testing.