CS 411 Triton Lab III - Prototype Test Plan Paper.doc

Triton Team

Lab III

Prototype Test Plan/Procedure

Date: 04/28/2008

Triton Lab III – Prototype Test Plan/Procedure

Table of Contents

1 Objective.......................................................................................................................32 References....................................................................................................................43 Test Plan.......................................................................................................................5

3.1 Testing Approach...................................................................................................53.2 Identification of Tests..............................................................................................73.3 Test Schedule.........................................................................................................83.4 Fault Reporting and Data Recording......................................................................93.5 Resource Requirement...........................................................................................93.6 Test Environment.................................................................................................103.7 Test Responsibilities.............................................................................................12

4 Test Procedures..........................................................................................................124.1 RuBee™ Setup Test Cases..................................................................................134.2 RuBee™ Communication Test Cases..................................................................144.3 Triton System Prototype Software Test Cases.....................................................154.4 Access Database Test Cases...............................................................................194.5 System Scenarios Test Cases..............................................................................20

5 Traceability to Requirements......................................................................................22

List of Tables

Table 1 - Triton Prototype Test Identification...................................................................8Table 2 - Triton Prototype Test Sequence.......................................................................9Table 3 - Triton Prototype Test Resource Requirements...............................................10Table 4 - Demonstration Responsibilities and Assignment............................................12Table 5 - RuBee™ Tests................................................................................................13Table 6 - RuBee™ Communication Tests.................................................................14-15Table 7 - Triton System Prototype Software Tests...................................................15-19Table 8 - Access Database Tests..................................................................................19Table 9 - System Scenarios Test..............................................................................20-22Table 10 - Traceability matrix for the Triton prototype....................................................23

List of Figures

Figure 1 - Triton Prototype Architecture...........................................................................6Figure 2 - ECS Conference Room Layout......................................................................11

2


1 Objective

The purpose of the Test Plan/Procedure document is to establish the overall

approach, testing sequence, and specific tests to be conducted to demonstrate

successful operation of the Triton prototype. The Triton prototype will demonstrate that

its sensor based surveillance system is feasible. Triton will prove four functional

objectives: underwater communication between RuBeeTM tags and an antenna

connected to a RuBeeTM receiver, detection of possible drowning scenarios, output, and

access control. The first functional objective deals with underwater communication. It is

very important to successfully demonstrate that RuBeeTM tags can send signals to a

RuBeeTM receiver. The RuBeeTM receiver will use an antenna to capture signals from

RuBeeTM tags; furthermore, Triton will use the RuBeeTM Finder Software, provided by

Visible Assets Inc., to show the unique ID of each RuBeeTM tag that is read by the

antenna. The RuBeeTM receiver will transfer the data to a laptop, provided by the ODU

Computer Science department, used to simulate the base station where the RuBeeTM

Finder Software will be installed.

The second functional objective deals with the detection of possible drowning

scenarios. Based on a formula and pre-established parameters such as water density,

gravity, atmospheric pressure, and the swimmer’s arm length, the formula returns the

depth of the swimmer. In addition, the Triton System Prototype Software needs data

from a wet/dry and pressure sensor, which will be simulated, to determine when a

swimmer is in the pool and underwater. The formula is applied every second. A

drowning scenario is determined if a swimmer is in the pool, underwater, and his depth

does not change after 15 seconds.

3


The third functional objective deals with the Triton System Prototype Software’s

output. The output is based on three elements: alarm, location, and archive file. Once a

drowning scenario is determined, the Pool Alert View Interface, part of the Triton

System Prototype Software, notifies lifeguards about the hazardous situation through a

pop-up window alarm; furthermore, the Pool Alert View Interface displays the swimmer’s

information and pool location. In addition, the information of the victim such as date,

time, and depth is stored into an archive file. The file is updated every time a drowning

scenario occurs.

The fourth functional objective deals with access control. Only users with a valid

username and password will have access to the system. When the Pool Alert View

Interface issues an alarm, only authorized users such as lifeguards or administrators will

be able to acknowledge the alarm and disable it. In order to disable the alarm, the

authorized users must verify that the victim is no longer underwater by checking the

pool and Pool Alert View Interface. To demonstrate how the Triton System Prototype

Software works, Triton will use pre-seeded data to simulate different swimmer

scenarios.

2 References

Barbieri, Cesar. (2008). Lab 1.1 – Triton Product Description. Virginia Beach, VA:

Author.

Barbieri, Cesar. (2008). Lab 2.1 – Prototype Product Specification for Triton. Virginia

Beach, VA: Author.

4


Red Team. (2007). Room Diagram. [Figure 2]. Figure created during CS411 at Old

Dominion University. Retrieved April 14, 2008 from CPI website:

http://www.cs.odu.edu/~cpi/cpi-2-s2007/himms/diagrams.htm.

Orange Team. (2007, November). Triton Risk Management Plan. Retrieved April 23,

2008, from Triton Web site: http://www.cs.odu.edu/~cpi/cpi-f2007/triton/docs/

RiskManagementPlan.doc. Document created during CS 410 at Old Dominion

University.

3 Test Plan

The following sections will describe the types of test, methods, and tools that are

required to validate the Triton prototype. The purpose of each test is to verify that each

requirement is met. Each test will be performed in sequential order and according to

Triton’s test schedule. The result of each test will be recorded by a Triton member. The

results will be used to improve the quality of the Triton prototype.

3.1 Testing Approach

The Triton prototype performance will be verified by a successful demonstration

of each major component of the Triton Prototype Architecture and through a series of

tests cases. The components of the Triton Prototype Architecture are shown in Figure 1.

[This space is intentionally left blank]

5


Figure 1 - Triton Prototype Architecture

Performance will be verified through the following components and system level

tests:

1. RuBeeTM Setup tests will verify that all hardware and software is

connected and installed properly for an optimum performance.

2. RuBeeTM Communication tests will verify that communication out-of-

water, underwater, and through concrete is possible.

3. Triton System Prototype Software tests will verify that each of the

seven interfaces of the Triton prototype software work as intended.

4. Access Database tests will verify the database tables’ schema and the

connection with the software application.

6


Since dry/wet and pressure sensor’s readings will be simulated, testing at

hardware and software integration level will not be required. All tests will be conducted

in a controlled ODU classroom environment. An aquarium filled with water and a brick

will be used to test RuBeeTM transmission capabilities. During the Triton System

Prototype Software tests, pre-seeded data will be used to simulate different system

users, swimmers, and drowning scenarios; however, the system will be capable of

adding and deleting new system users and swimmers. Verification of the Triton System

Prototype Software and Access Database tests will be completed through observation

and by verifying the archive log, which will be updated every time the software detects a

drowning scenario. In addition, risks will be mitigated. Test 1 and test 2 will help mitigate

RuBeeTM software and hardware interoperability; furthermore, since the RuBeeTM Finder

Software displays only operating tags, it will help mitigate unit malfunctioning. False

positives will be mitigated by testing the system’s Pool Alert View Interface functionality

(Orange Team, 2007).

3.2 Identification of Tests

Table 1 shows a list of test cases that will be performed to validate each

component of the Triton prototype. The test cases are grouped in four categories:

RuBeeTM Setup, RuBeeTM Communication, Triton System Prototype Software, and

Access Database. A detailed description of each test case will be discussed in sections

4.1 through 4.4.


7


Category ID DescriptionTest Case

Description

1 RuBeeTM Setup1.1 Hardware connection1.2 Software operation verification

2RuBeeTM

Communication

2.1 Dry environment communication2.2 Underwater communication2.3 Underwater-brick communication2.4 Integration testing with multiple tags

3Triton System

Prototype Software

3.1 User Login Interface3.2 Swimmer Registration Interface3.3 Swimmer Administration Interface3.4 Pool Alert View Interface3.5 Prototype Detection Algorithm3.6 Prototype Settings Interface3.7 User Administration Interface

4 Access Database4.1 Verify Login table4.2 Verify ID table

5 System Scenarios

5.1 Swimmer outside the pool5.2 Swimmer in the pool, but above water level5.3 Swimmer in the pool moving down and up5.4 Swimmer drowning5.5 Multiple Swimmers

Table 1 - Triton Prototype Test Identification

3.3 Test Schedule

Triton will have 45 minutes for the setup and demonstration of the prototype. The

first five minutes will be used to set up the hardware and software required for the

demonstration. A ten minutes introduction to the scope, concepts, and feasibility of the

Triton System will follow. The last 30 minutes of the demonstration will be used to

execute the test cases in accordance with the schedule shown in Table 2.


8


Start Time (Hours:Min)

Duration(Minutes)

Test ObjectiveTest

EventDependencies Comments

0:15 10 RuBeeTM Communication

2.1, 2.2 2.3, 2.4

None None

0:25 2 Access Database

4.1, 4.2 None None

0:27 3 Simulated Data 3.6 None None0:30 15 Triton System

Prototype Software

3.1-3.7, 5.1-5.5

None None

Table 2 - Triton Prototype Test Sequence

3.4 Fault Reporting and Data Recording

Two members of the Triton team will be designated to record the results of each

functional test on a printed checklist and on a power point slide during the prototype

demonstration. The purpose of the slides is to help the review panelists, during the

prototype demonstration, to easily track the results of each test. If a test result is

positive, the test will be marked as pass; otherwise, it will be marked as fail. Comments

will be recorded based on each test’s result and any error message. Triton System

Prototype Software tests results will be verified by observing the response and output of

each interface. Access Database tests results will be verified by observing the

information stored in the database. Performance tests will be verified by comparing the

results with the performance requirements.

3.5 Resource Requirement

The Triton prototype demonstration will require an ODU laptop, a RuBeeTM demo

kit, an aquarium filled with water, a brick, a projector, Microsoft Access, Microsoft .NET

9


Framework, Microsoft PowerPoint, and the Triton System Prototype Software. Table 3

summarizes a detailed description of each resource.

Resource Name DescriptionODU laptop Laptop is provided by Old Dominion University

Department of Computer Science. Laptop should include a USB or a RS 232 communication port and an operating system of Windows XP or Vista

RuBeeTM demo kit The kit includes tags, a receiver, antennas, a demo kit manual, accessories, and RuBeeTM Finder Software

The aquarium The aquarium is purchased by Old Dominion University Department of Computer Science

The brick The brick is provided by Janet Brunelle from her backyardTriton Prototype Software The software includes seven interfaces as shown in figure

1 - Triton Prototype Architecture. The software interacts with an Access database and uses simulated, pre-seeded swimmer data

Microsoft Access Microsoft Access is used to create the database for the Triton Prototype Software

Microsoft .NET Framework Microsoft .NET Framework is required to run the Triton System Prototype Software

Microsoft PowerPoint Microsoft PowerPoint is used during the feasibility presentation

Projector A projector is essential for the feasibility presentationTable 3 - Triton Prototype Test Resource Requirements

3.6 Test Environment

The prototype demonstration will take place in the Engineering and

Computational Science building’s conference room on the ODU campus. Figure 2

shows the layout of this room.


10


Figure 2 - ECS Conference Room Layout

The elements required during the demonstration are the RuBeeTM demo kit,

aquarium, brick, and laptop. These elements will be placed on the table at the left side

of Laptop 1, which is in front of the Panel of Experts. The two Triton members that will

use the elements to demonstrate underwater communication will be seated in front of

the Panel of Experts. One team member will be responsible for using the aquarium and

operating the RuBeeTM hardware while the other will be responsible for operating the

RuBeeTM Finder Software. The team member demonstrating the Triton System

Prototype Software will use Laptop 1 and will sit in front of it; furthermore, this team

member will use Projector Screen 2 to visually guide the panel of experts through each

step of the demonstration.

11


3.7 Test Responsibilities

Kate Nguyen will be responsible for introducing the Triton team to the panel of

experts and concluding the overall presentation; also, she will be one of the test

recorders. Dave Larnerd will be responsible for delivering the Triton’s feasibility

presentation and will be responsible for demonstrating RuBeeTM underwater

communication. Cesar Barbieri will be responsible for demonstrating RuBeeTM

underwater communication and record the results of each test. Brandon Simpkins will

be responsible for the demonstration of the Triton System Prototype Software. All

members will field questions at the end of the presentation. Table 4 summarizes the list

of team members and their responsibilities.

Team Member Responsibility

Cesar Barbieri RuBeeTM underwater communication Data recording

Kate Nguyen Introduction Conclusion Data recording

Dave Larnerd Feasibility presentation RuBeeTM underwater communication

Brandon Simpkins Triton System Prototype demonstration Table 4 - Demonstration Responsibilities and Assignment

4 Test Procedures

A list of detailed tests has been prepared to ensure the Triton prototype’s

optimum performance. Each category has been divided into test cases that are

discussed in the following sections.


12


4.1 RuBee™ Setup Test Cases

Table 5 describes the RuBeeTM Setup test cases activities and their expected results.

Test Category ID: 1 Description: RuBeeTM Setup: Hardware connectionTest Case: 1.1 Purpose: This test will verify that the RuBeeTM can be connected and

integratedSetup Conditions: RuBeeTM demo kit required

Test Case Activity Pass/Fail Comments Expected Result1 Plug in the power supply and

connect it to the receiver The power light illuminates on the receiver

2 Connect the receiver to the ODU laptop’s RS-232 serial or USB port using the null modern cable

The laptop recognizes the receiver

3 Connect the antenna to the receiver

The Finder Software should recognize the receiver

Test Category ID: 1 Description: RuBeeTM Setup: Software operation verificationTest Case: 1.2 Purpose: This test will verify that the RuBeeTM Finder Software can

operate on the ODU student laptopSetup Conditions: RuBeeTM Finder Software and ODU laptop required

Test Case Activity Pass/Fail Comments Expected Result1 Locate the RuBeeTM Finder

Software icon The icon is found

2 Open the Finder Software by double clicking on it

The software can be opened

3 Verify that the software can recognize the antenna and the receiver

The antenna, tags, and receiver are verified by the software

Table 5 - RuBee™ Tests

[This page is intentionally left blank]

13


4.2 RuBee™ Communication Test Cases

Table 6 describes the RuBeeTM Communication test cases activities and their

expected results.

Test Category ID: 2 Description: RuBeeTM Communication: Dry environment communicationTest Case: 2.1 Purpose: This test will verify that RuBeeTM tags can transmit in a dry

environmentSetup Conditions: Test 1.1 and 1.2 should be successfully completed

Test Case Activity Pass/Fail Comments Expected Result1 Position the tag outside of

aquarium and within antenna range

Tag ID is displayed on the RuBeeTM Finder Software screen

2 Position the tag outside of aquarium and outside of antenna range

Tag ID is not displayed on the RuBeeTM Finder Software screen

Test Category ID: 2 Description: RuBeeTM Communication: Underwater communicationTest Case: 2.2 Purpose: This test will verify that RuBeeTM tags can transmit underwater

Setup Conditions: Test 1.1 and 1.2 should be successfully completedTest Case Activity Pass/Fail Comments Expected Result1 Position the tag inside of


The tag ID is displayed on the RuBeeTM Finder Software screen

Test Category ID: 2 Description: RuBeeTM Communication: Underwater-brick communicationTest Case: 2.3 Purpose: This test will verify that RuBeeTM tags can transmit underwater

and through a brickSetup Conditions: Test 1.1 and 1.2 should be successfully completed

Test Case Activity Pass/Fail Comments Expected Result1 Position the tag inside of the

aquarium, under the brick, and within antenna range

The tag ID is displayed on the RuBeeTM Finder Software screen


Test Category ID: 2 Description: RuBeeTM Communication: Integration testing with multiple tags

14


Test Case: 2.4 Purpose: This test will verify that multiple RuBeeTM tags can transmit underwaterSetup Conditions: Test 1.1 and 1.2 should be successfully completed

Test Case Activity Pass/Fail Comments Expected Result1 Position all tags inside of


Each tag ID is displayed on the RuBeeTM Finder Software screen

Table 6 - RuBee™ Communication Tests

4.3 Triton System Prototype Software Test Cases

Table 7 describes the Triton System Prototype Software test cases activities and

their expected results.

Test Category ID: 3 Description: Triton System Prototype Software: User Login InterfaceTest Case: 3.1 Purpose: This test will verify that the User Login Interface accepts

authorized users and rejects unauthorized users. Also, verified users are granted appropriate accessSetup Conditions: Triton System Prototype installed and running on ODU laptop

Test Case Activity Pass/Fail Comments Expected Result1

Invalid username and/or password attempt login

An error message is displayed and system access is not granted

2 Administrator user type attempt login

Full system access granted

3 Cashier user type attempt login

System access granted to Swimmer Registration, Swimmer Administration, and Prototype Settings

4Lifeguard user type attempt login

System access granted to Pool Alert View and Prototype Settings


Test Category ID: 3 Description: Triton System Prototype Software: Swimmer Registration

15


InterfaceTest Case: 3.2 Purpose: This test will verify that the Swimmer Registration Interface

allows the addition of new swimmersSetup Conditions: Triton System Prototype installed and running on ODU laptop. Swimmer Registration Interface tab is selected

Test Case Activity Pass/Fail Comments Expected Result1 Add a new swimmer by filling

out all fields listed in Lab II Prototype Product Specification for Triton section 3.1.4.1 and 3.1.4.2

New swimmer is added and visible in the Swimmer Administration Interface

2 Add a new swimmer filling out all fields listed in Lab II Prototype Product Specification for Triton section 3.1.4.1 with a wristband that is already in use

New swimmer is not added and an error message is displayed

Test Category ID: 3 Description: Triton System Prototype Software: Swimmer Administration Interface

Test Case: 3.3 Purpose: This test will verify that the Swimmer Administration Interface allows the removal of individual swimmers or all registered swimmersSetup Conditions: Triton System Prototype installed and running on ODU laptop. Swimmer Administration Interface tab is selected

Test Case Activity Pass/Fail Comments Expected Result1 Select a swimmer from the

swimmer selection listSwimmer’s information is displayed

2 Select one swimmer from the swimmer selection list and click Remove Swimmer button to remove swimmer

Selected swimmer is removed and visibly verifiable in the Swimmer Administration Interface

3 Select Clear Fields button to remove all active swimmers

All swimmers are removed


Test Category ID: 3 Description: Triton System Prototype Software: Pool Alert View Interface

16


Test Case: 3.4 Purpose: This test will verify that the Pool Alert View Interface provides a visual representation of all the swimmers and alarms the lifeguard of a potential drowning victimSetup Conditions: Triton System Prototype installed and running on ODU laptop. Pool Alert View Interface tab is selected

Test Case Activity Pass/Fail Comments Expected Result1 Verify that a list of active

swimmers is displayed in the Safe Swimmers box

A list of active swimmers is displayed in the Safe Swimmers box

2 Verify that potential drowning victims are displayed in the Potential Drowning Victims box

A list of potential drowning victims is displayed in the Potential Drowning Victims box

3 Simulation of a potential drowning victim (see test case 3.6 for detail)

An alarm message will be displayed and the location of the victim will be highlighted on the aerial view of the pool and all active swimmers’ data is archived

4 Disable an alarm with a proper username and password. Potential drowning victim is no longer underwater

Alarm is disabled

5 Disable an alarm with a proper username and password. Potential drowning victim is still underwater

Alarm is not disabled

6 Disable an alarm with invalid combination of username and password

Alarm is not disabled

7 Step through simulated scenario

Scenario results display second by second view where a user can progress and digress through the scenario


17


Test Category ID: 3 Description: Triton System Prototype Software: Prototype Detection Algorithm Interface

Test Case: 3.5 Purpose: This test will verify that the Prototype Detection Algorithm Interface can calculate the depth of a swimmer using simulated sensor readings, swimmer arm length, and environments constantsSetup Conditions: Triton System Prototype installed and running on ODU laptop. Prototype Detection Algorithm Interface tab is selected

Test Case Activity Pass/Fail Comments Expected Result1 Fill out the required fields under

Sensor Readings and Environment Variables

The swimmers’ depth is displayed

Test Category ID: 3 Description: Triton System Prototype Software: Prototype Settings InterfaceTest Case: 3.6 Purpose: This test will verify that the Prototype Settings Interface loads

swimmers’ data and swimmers’ scenarios into the Triton System Prototype SoftwareSetup Conditions: Triton System Prototype installed and running on ODU laptop. Prototype Settings Interface tab is selected

Test Case Activity Pass/Fail Comments Expected Result1 Select the swimmers information

file. Click the load buttonSwimmers’ data loaded and viewable through the Swimmer Administration Interface

2 Select the swimmer scenario file. Click the load button

Swimmers’ scenario loaded and viewable through the Pool Alert View Interface


18


Test Category ID: 3 Description: Triton System Prototype Software: User Administration Interface

Test Case: 3.7 Purpose: This test will verify that the User Administration Interface adds users to the login database tableSetup Conditions: Triton System Prototype installed and running on ODU laptop. User Administration Interface tab is selected

Test Case Activity Pass/Fail Comments Expected Result1 Add a new user to the system by

entering username, password, and user type

New user added to the database

2 List all valid users Display of all valid users3 Remove user(s) from the

system.User(s) removed from the database.

4 Reset a user’s password Old password in database is deleted. New password is saved in database

Table 7 - Triton System Prototype Software Tests

4.4 Access Database Test Cases.

Table 8 describes the Access Database test cases activities and their expected

results.

Test Category ID: 4 Description: Access Database: Login tableTest Case: 4.1 Purpose: This test will verify that the database contains a login table

Setup Conditions: Microsoft Access installed and running on ODU laptopTest Case Activity Pass/Fail Comments Expected Result1 Check Login table schema as

specified in Lab II Prototype Product Specification for Triton section 3.1.9.1

Login table has the required schema

Test Category ID: 4 Description: Access Database: ID tableTest Case: 4.2 Purpose: This test will verify that the database contains an ID table

Setup Conditions: Microsoft Access installed and running on ODU laptopTest Case Activity Pass/Fail Comments Expected Result1 Check ID table schema as

specified in Lab II Prototype Product Specification for Triton section 3.1.9.2

ID table has the required schema

Table 8 - Access Database Tests

19


4.5 System Scenarios Test Cases.

Table 9 describes the System Scenarios test cases activities and their expected

results.

Test Category ID: 5 Description: System Testing: Swimmer outside the poolTest Case: 5.1 Purpose: This test will verify the behavior of the Triton System Prototype

Software with one swimmer outside the waterSetup Conditions: The Triton System Prototype Software and Access Database must be installed and running properly; furthermore, the Pool Alert View tab must be selected

Test Case Activity Pass/Fail Comments Expected Result1 Load swimmer outside the pool

scenarioA successful loading scenario message is displayed

2 Click on the desired swimmer’s wristband ID

The swimmer ID is highlighted and a brown dot representing the location of the swimmer outside the pool is displayed

3 Click the Next and Previous buttons to step through the scenario in one second interval

Simulated swimmer in the pool will move.

Test Category ID: 5 Description: System Testing: Swimmer in the pool, but above water levelTest Case: 5.2 Purpose: This test will verify the behavior of the Triton System Prototype

Software with one swimmer in the waterSetup Conditions: The Triton System Prototype Software and Access Database must be installed and running properly; furthermore, the Pool Alert View tab must be selected

Test Case Activity Pass/Fail Comments Expected Result1 Load swimmer in the pool, but

above water level scenarioA successful loading scenario message is displayed


The swimmer ID is highlighted and a brown dot representing the location of the swimmer above the water level is displayed


Simulated swimmer in the pool will move.

20


Test Category ID: 5 Description: System Testing: Swimmer in the pool moving down and upTest Case: 5.3 Purpose: This test will verify the behavior of the Triton System Prototype

Software with one swimmer in the water moving down and upSetup Conditions: The Triton System Prototype Software and Access Database must be installed and running properly; furthermore, the Pool Alert View tab must be selected




The swimmer ID is highlighted and a brown dot representing the location of the swimmer underwater is displayed


Simulated swimmers in the pool will move. When the swimmer is underwater, the brown dot changes to blue

Test Category ID: 5 Description: System Testing: Swimmer drowningTest Case: 5.4 Purpose: This test will verify the behavior of the Triton System Prototype

Software with one swimmer drowningSetup Conditions: The Triton System Prototype Software and Access Database must be installed and running properly; furthermore, the Pool Alert View tab must be selected




The swimmer ID is highlighted and a brown dot representing the location of the swimmer is displayed


Simulated swimmer in the pool will move. When the swimmer is underwater, the brown dot changes to blue. If the swimmer is drowning, a pop-up window alarm will be displayed

4 Make sure the swimmer is no Alarm is deactivated

21


longer underwater and enter the username and password to deactivate the alarm.

Test Category ID: 5 Description: System Testing: Multiple swimmersTest Case: 5.5 Purpose: This test will verify the behavior of the Triton System Prototype

Software with multiple swimmersSetup Conditions: The Triton System Prototype Software and Access Database must be installed and running properly; furthermore, the Pool Alert View tab must be selected

Test Case Activity Pass/Fail Comments Expected Result1 Load multiple swimmers

scenarioA successful loading scenario message is displayed


Simulated swimmers in the pool will move and events described in test cases 5.1 – 5.4 will be illustrated

Table 9 - System Scenarios Test

5 Traceability to Requirements

Each test case has been designed to verify that one or more prototype

requirements are met. The traceability matrix shown in Table 10 illustrates the

relationship between requirements and test cases.


22


Requirements Test CasesComponent Req ID 1.1 1.2 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.1 4.2 5

RuBeeTM Setup 3.1.1 X X

Underwater Communication

3.1.2.1 X X3.1.2.2 X X3.1.2.3 X X

User Login Interface

3.1.3.1 X3.1.3.2 X3.1.3.3 X3.1.3.4 X

3.1.3.5 XSwimmer Registration Interface

3.1.4.1 X

3.1.4.2 X

Swimmer Administration Interface

3.1.4.3 X

3.1.4.4 X

Pool Alert View Interface

3.1.5.1 X X3.1.5.2 X X3.1.5.3 X X3.1.5.4 X X

Prototype Detection Algorithm Interface

3.1.6.1 X X3.1.6.2 X X3.1.6.3 X X

3.1.6.4 X XPrototype Settings Interface

3.1.7.1 X3.1.7.2 X

User Administration Interface

3.1.8.1 X

3.1.8.2 X

3.1.8.3 X

3.1.8.4 X

3.1.8.5 X

Access Database3.1.9.1 X

3.1.9.2 X

Simulated Data3.1.10.1 X X

3.1.10.2 X X

Swimmer Simulation

3.1.11.1 X X

3.1.11.2 X X

3.1.11.3 X X

3.1.11.4 X XTable 10 - Traceability matrix for the Triton prototype

23

CS 411 Triton Lab III - Prototype Test Plan Paper.doc

Documents

Transcript of CS 411 Triton Lab III - Prototype Test Plan Paper.doc