acceptance test plan - drexel universitydpn52/therawii/acc_plan.pdf · acceptance test plan...

Acceptance Test Plan

TheraWii

Tim ChagnonJoe Kokinda

Andrew MeinertDon Naegely

February 18, 2009Revision 11

Acceptance Test Plan Revisions

Date Description Revision Editor11/26/2008 Created the document 0 Don Naegely11/26/2008 Created all sections and labels 1 Don Naegely11/30/2008 Added content to the Introduc-

tion section2 Joe Kokinda

11/30/2008 Updated Test Approach andConstraints sections

3 Joe Kokinda

11/30/2008 Updated test case format andadded sample test case

4 Don Naegely

11/30/2008 Updated the Introduction sec-tion

5 Don Naegely

12/1/2008 Added main test cases 6 Tim Chagnon12/1/2008 Added test cases TC2–TC6 7 Don Naegely12/1/2008 Added test cases TC8–TC16 8 Joe Kokinda12/2/2008 Edited everything but the Test

Cases section9 Don Naegely

12/2/2008 Added links to SRS 10 Don Naegely12/2/2008 Edited the test cases and made

style consistent11 Don Naegely

i

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Test Approach and Constraints 12.1 Test Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Test Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Test Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Test Assumptions and Exclusions 23.1 Test Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 Test Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

4 Entry and Exit Criteria 24.1 Entry Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34.2 Exit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

5 Testing Participants 35.1 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35.2 Training Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35.3 Problem Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35.4 Progress Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

6 Test Cases 46.1 Add a New Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46.2 Delete a Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46.3 Add a Dialog Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56.4 Add a Repeat Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.5 Add a 2-D Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76.6 Edit a Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86.7 Copy and Paste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.8 Delete Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.9 Rearrange Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116.10 Run a Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.11 Add a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.12 Delete a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.13 View a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156.14 Export a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156.15 Delete a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.16 Import a Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.17 Export a Therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.18 Import a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.19 Export a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ii

Acceptance Test Plan TheraWii

1 Introduction

1.1 Background

This document provides the process for completing the acceptance test of the TheraWii software system.The process was influenced by the Software Requirements Specification (see §1.2) which governed the designand implementation of the system.

1.2 References

• TheraWii SRS—The following URL provides a link to the most recent version: https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/req_doc/srs.pdf

1.3 Definitions and Acronyms

1.3.1 Physical Therapy

Posture The orientation of any body segment relative to the gravitational vector. It is an angular measurefrom the vertical.

Balance The dynamics of body posture that prevents falling. It is related to the inertial forces acting onthe body and the inertial characteristics of body segments.

Center of Mass (COM) A specific point at which the system’s mass behaves as if it were concentrated.

Center of Pressure (COP) The point location of the vertical ground reaction force vector. It representsa weighted average of all the pressures over the surface of the area that is in contact with the ground.It is also called the Center of Balance (COB).

1.3.2 Nintendo Wii

Wii Remote Device that communicates through Bluetooth wireless protocol to the Nintendo Wii Gam-ing System. Data communicated includes button press and releases, accelerometer readings, and aninfrared (IR) LED pointing system.

Wii Balance Board Device that communicates the COP through Bluetooth wireless protocol to the Nin-tendo Wii Gaming System.

1.3.3 Software

Therapy A series of tasks that is completed in one session.

Session A given time in which a user completes a therapy.

Task A subunit of a therapy that has an objective with success and fail criteria.

Test Case A single, atomic test made up of preconditions that must be satisfied, actions that will becompleted by the tester, and postconditions that specify the expected behavior.

2 Test Approach and Constraints

This section shall describe the objectives, structure, and constraints for the acceptance test plan of theTherawii software.

February 18, 2009 1

https://baloo.cs.drexel.edu/trac/therawii/export/HEAD/doc/req_doc/srs.pdf



2.1 Test Objectives

The main objective of the Acceptance Test Plan is to verify that the Therawii software follows all therequirements and functionality specified in the Therawii Requirements Document.The Acceptance Test Plan will provide the criteria to define if the project is a success or a failure.

2.2 Test Structure

Each scenario shall consist of a precondition, an action, a postcondition, and the specifications that arecovered by the scenario. The precondition shall describe the state of the software before the tested actionoccurs. The action is what is being tested. The postcondition is the desired state of the software after thetested action. The specifications will be a list of the requirements that the scenario tests.

2.3 Test Constraints

The Acceptance Test Plan will be limited to testing the functionality of the software as defined in theTheraWii Requirements Document. It will not test the design and implementation of the TheraWii sourcecode.

3 Test Assumptions and Exclusions

This section provides greater details about which functions and features of TheraWii will be covered by theAcceptance Test Plan process, and which functions of TheraWii will not be covered.

3.1 Test Assumptions

It is assumed that all issues covered by the Acceptance Test Plan were also previously addressed by unittests, integration tests and system tests of TheraWii. The Acceptance Test plan will cover

• functional requirements of the system listed in the Software Requirements Specification,

• consistency of user related system documentation.

3.2 Test Exclusions

It is assumed that all issues not covered by the Acceptance Test Plan were previously addressed by unittests, integration tests, and system tests. The Acceptance Test Plan will not cover

• systems outside the scope of Hardware and Software Constraints listed in the Software RequirementsSpecification,

• structural integrity of the source code.

4 Entry and Exit Criteria

This section lists the criteria which must be satisfied in order for the Acceptance Test Plan to begin, as wellas the criteria which must be satisfied in order for the Acceptance Test Plan to stop.

February 18, 2009 2


4.1 Entry Criteria

The Acceptance Test can begin after the following conditions have been met.

• All other unit tests, system tests and integration tests are complete.

• A proper environment that meets Software r4.6.1 and Hardware r4.6.2 constraints outlined in the SRSis available.

• A copy of the latest version of the SRS has been received.

• The latest version of TheraWii has been compiled and installed.

• Consent from the Team Leader.

• Consent from the Client Representative.

4.2 Exit Criteria

The Acceptance Test Plan should be halted after either of the following:

• All Priority 1 requirements were tested without deviation from expected behvior (Success).

• At least one Priority 1 requirement deviated from the documented specification (Failure).

5 Testing Participants

This section describes the roles and responsibilities of the parties involved in the Acceptance Test Plan, aswell as the procedure for reporting the test results.

5.1 Roles and Responsibilities

• Test team leader: Tim Chagnon

• Client representative: Carole Tucker

• Testers: Joe Kokinda, Andrew Meinert, Don Naegely

5.2 Training Requirements

All parties involved in the Acceptance Test Plan should be comfortable with standard Windows applicationinterfaces. All parties should be familiar with the user interface of TheraWii, as well as with the systemdocumentation and the Software Requirements Specification.

5.3 Problem Reporting

Any problem discovered by either the Client Representative or a Tester must be documented and reportedto the Test Team Leader. The problem report will be submitted to the Team Leader and addressed duringa periodic or special meeting depending on the severity of the problem.

5.4 Progress Reporting

The Acceptance Test Plan Report will be compiled after the testing process has been completed by the TestTeam Leader and submitted to the Team Leader.

February 18, 2009 3




6 Test Cases

6.1 Add a New Therapy

ID TC 1Name Add a New TherapyRequirement(s) §4.4.3 and r4.2.8Description The user adds a new therapy to the system.Precondition(s)

• The user has started the TheraWii software.

• The user has entered Therapy Management mode.

Action(s)

1. The user clicks the “Add” button under the list of current therapies.

2. The user enters the new therapy name when the dialog box appears.

3. The user clicks “OK” in the dialog box.

Postcondition(s)

• The list of therapies contains a new entry with the name the user justentered.

• The new therapy has no tasks associated with it.

6.2 Delete a Therapy

ID TC 2Name Delete a TherapyRequirement(s) §4.4.3 and r4.2.7.*Description The user removes a therapy from the system.Precondition(s)



Action(s)

1. The user selects a therapy from the list of therapies.

2. The user clicks the “Remove” button under the list of current therapies.

3. The user clicks “Yes” in the confirm delete dialog that appears.

Postcondition(s)

• The list of therapies no longer contains an entry with the name of thepreviously deleted therapy.

• The order of therapies is unchanged except for the absence of the removedtherapy.

February 18, 2009 4






6.3 Add a Dialog Task

ID TC 3Name Add a Dialog TaskRequirement(s) §4.4.4, r4.3.8.*, and r5.1.1.*Description The user adds a new task of type “Dialog”Precondition(s)



• The user has selected a therapy.

Action(s)

1. The user clicks on the “New Task” button.

2. The user selects “Dialog” from the available task types.

3. The user configures the rest of the task parameters in the task editorwindow.

4. The user clicks the “Save” button to record the new task.

Postcondition(s)

• The previously selected therapy is still selected.

• The list of tasks is unchanged with the exception of the additional taskname.

February 18, 2009 5





6.4 Add a Repeat Task

ID TC 4Name Add a Repeat TaskRequirement(s) r4.3.8.* and r5.1.4.*Description The user adds a new task of type “Repeat”Precondition(s)




Action(s)


2. The user selects “Repeat” from the available task types.



Postcondition(s)



February 18, 2009 6




6.5 Add a 2-D Task

ID TC 5Name Add a 2-D TaskRequirement(s) §4.4.5, r4.3.8.*, and r5.1.2.*Description The user adds a new task of type “2-D”Precondition(s)




Action(s)


2. The user selects “2-D” from the available task types.



Postcondition(s)



February 18, 2009 7





6.6 Edit a Task

ID TC 6Name Edit a TaskRequirement(s) §4.4.4, §4.4.5, and r4.3.9.*Description The user edits an existing task.Precondition(s)



• The user has selected a therapy with at least one task associated with it.

Action(s)

1. The user selects a task from the list of tasks.

2. The user clicks “Edit Task.”

3. The user modifies the parameters of the task in the task editor window.

4. The user clicks “Save” in the task editor window.

Postcondition(s)

• If the name of the task changed, the new name is shown in the list oftasks.

• The previously selected therapy is still selected and all previously dis-played tasks are still displayed.

• The parameters of the task are recorded in the system such that if thetask is edited again, the modifications made by the user persist.

February 18, 2009 8





6.7 Copy and Paste

ID TC 7Name Copy and PasteRequirement(s) §3.4.*Description The user copies text and pastes it in another locationPrecondition(s)


• The user has selected text.

Action(s)

1. The user clicks on the “Edit” menu and selects ”copy”.

2. The user selects a text input field.

3. The user clicks the “Edit” menu and selects paste.

Postcondition(s)

• The selected text is stored in the clipboard.

• The contents of the clipboard is inserted into the input field.

6.8 Delete Tasks

6.8.1 Delete Single Selected Task

ID TC 8Name Delete Single Selected TaskRequirement(s) r4.3, r4.3.1–r4.3.7, and r4.3.7.1–r4.3.7.4Description The test case verifies the software’s ability to delete a specific task from a given

therapy. A therapy must exist with at least one task associated with it. Theuser must be able to select a task and then click the “Delete Task” button todelete it from the therapy.

Precondition(s)

• A therapy exists with at least one task associated with it.

• The user has the ability to select a single task in the therapy.

Action(s)

1. The user selects a therapy and then a single task within the therapy.

2. The user clicks the “Delete Task” button.

Postcondition(s)

• A dialog box appears requesting verification of the deletion.

• After the action has been confirmed, the order of the remaining tasksshould be the same.

February 18, 2009 9








6.8.2 Delete Multiple Selected Tasks

ID TC 9Name Delete Multiple Selected TasksRequirement(s) r4.3, r4.3.1–r4.3.7, and r4.3.7.1–r4.3.7.4Description The test case verifies the software’s ability to delete a number of tasks from a

given therapy. A therapy must exist with more than one task associated withit. The user must be able to select multiple tasks and click the “Delete Task”button to delete them from the therapy.

Precondition(s)

• A therapy exists with multiple tasks associated with it.

• The user has the ability to select multiple tasks in the therapy.

Action(s)

1. The user selects a therapy and then selects multiple tasks within thetherapy.

2. The user clicks the “Delete Task” button.

Postcondition(s)

• A dialog box appears requesting verification of the deletion.

• After the action has been confirmed, the order of the remaining tasksshould be the same.

6.8.3 Delete Zero Selected Tasks

ID TC 10Name Delete Zero Selected TasksRequirement(s) r4.3, r4.3.1–r4.3.7, and r4.3.7.1–r4.3.7.4Description The test case verifies that the software won’t changestate when the “Delete

Task” button is clicked and no tasks are selected.Precondition(s)

• N/A.

Action(s)

1. The user clicks the “Delete Task” button without any tasks selected.

Postcondition(s)

• The state of the software remains the same.

February 18, 2009 10












6.9 Rearrange Tasks

6.9.1 Move Task Up

ID TC 11Name Move Task UpRequirement(s) r4.3, r4.3.1–r4.3.6, r4.3.10, and r4.3.10.1Description The test case verifies the software’s ability to move a specific task from a given

therapy up one position. A therapy must exist with at least one task associatedwith it. The user must be able to select a task and then click the “Move Up”button to move the task up one position in the therapy.

Precondition(s)



Action(s)


2. The user clicks the “Move Up” button.

Postcondition(s)

• If the task is in the first position of the therapy, the task remains in thefirst position.

• If the task is not in the first position of the therapy, the task moves upone position making the task above it move down one position.








6.9.2 Move Task Down

ID TC 12Name Move Task DownRequirement(s) r4.3, r4.3.1–r4.3.6, r4.3.10, and r4.3.10.2Description The test case verifies the software’s ability to move a specific task from a given

therapy down one position. A therapy must exist with at least one task associ-ated with it. The user must be able to select a task and then click the “MoveDown” button to move the task down one position in the therapy.

Precondition(s)



Action(s)


2. The user clicks the “Move Down” button.

Postcondition(s)

• If the task is in the last position of the therapy, the task remains in thelast position.

• If the task is not in the last position of the therapy, the task moves downone position making the task below it move up one position.








6.10 Run a Therapy

ID TC 13Name Run a TherapyRequirement(s) r9.1–9.4Description The test case verifies the execution of a therapy. The user will select a therapy

to play and click the “Play” button.Precondition(s)


• The user has the ability to select a single therapy.

Action(s)

1. The user selects a single therapy.

2. The user clicks the “Play” button.

Postcondition(s)

• The software shall prompt user to sync devices required by all tasks inthe therapy.

• The software shall discover all available devices and prompt user to syn-cronize additional devices if required number of devices/device types arenot discovered or allow the user to cancel therapy exectution.

• The software shall enter full screen mode and begin the execution of theselected therapy.





6.11 Add a Profile

ID TC 14Name Add a ProfileRequirement(s) r6.2, r6.2.1–r6.2.6, r6.2.8, r6.2.8.1–r6.2.8.4Description The test case verifies the software’s ability to add a new profile to the Profile

Manager.Precondition(s)

• The software shall be in the Profile Manager section.

Action(s)

1. The user clicks the “New” button.

2. The user types the name of the new profile into the new window.

3. The user clicks the “OK” button.

Postcondition(s)

• The new profile shall appear in the list of profiles.

• If the “Cancel” button was clicked, there shall be no new profile added tothe records.

6.12 Delete a Profile

ID TC 15Name Delete a ProfileRequirement(s) r6.2, r6.2.1–r6.2.7, r6.2.7.1–r6.2.7.4Description The test case verifies the software’s ability to delete a profile from the Profile

Manager.Precondition(s)


• The Profile List must contain at least one profile.

Action(s)

1. The user selects a profile from the Profile List.

2. The user clicks the “Delete” button.

Postcondition(s)

• A new window appears confirming the deletions.

• If “Yes” is clicked, the profile shall be removed from the records and willnot appear in the Profile List.

• If “No” is clicked, the Profile List will not change state.














6.13 View a Session

ID TC 16Name View a SessionRequirement(s) r8.1 and r8.2Description The test case verifies the software’s ability to view a selected session from a

given profile.Precondition(s)


• The Profile List must contain at least one profile.

• A profile must contain at least one session.

Action(s)

1. The user selects a profile from the Profile List.

2. The user selects a session from the Session List.

3. The user clicks the “View Session” button.

Postcondition(s)

• A new window appears with the details described in r8.2.

6.14 Export a Session

ID TC 17Name Export a SessionRequirement(s) r7.1 r7.3, 8.1, and r8.2Description The user exports a session to CSV format.Precondition(s)

• There are at least one profile and one recorded session.

Action(s)

1. The user selects a profile.

2. The user selects a session from that profile.

3. The user clicks the “Export Session” button.

4. The user selects a file to save so.

Postcondition(s)

• The selected file contains the data from the session.









6.15 Delete a Session

ID TC 18Name Delete a SessionRequirement(s) r6.3.1–r6.3.7 and r6.3.7.1–r6.3.7.4Description The user deletes a session.Precondition(s)

• There are at least one profile and one recorded session.

Action(s)

1. The user selects a profile.

2. The user selects a session from that profile.

3. The user clicks the “Delete Session” button.

4. The user confirms his or her action.

Postcondition(s)

• The session is permanently removed.

6.16 Import a Therapy

ID TC 19Name Import a TherapyRequirement(s) r3.3.2Description The user imports a therapy from a file.Precondition(s)

• There is a therapy file accessible from the software.

Action(s)

1. The user selects “Import Therapy...” from the File menu.

2. The user selects the correct file to import.

Postcondition(s)

• The therapy is imported and thereafter displayed in the list of therapies.








6.17 Export a Therapy

ID TC 20Name Export a TherapyRequirement(s) r3.3.3, r7.4, r8.1, and r8.2Description The user exports a therapy to a file.Precondition(s)

• There is a therapy stored in the software.

Action(s)

1. The user selects “Export Therapy...” from the File menu.

2. The user selects the file to export to.

Postcondition(s)

• The selected file contains the therapy data.

6.18 Import a Profile

ID TC 21Name Import a ProfileRequirement(s) r3.3.4Description The user imports a profile from a file.Precondition(s)

• There is a profile file accessible from the software.

Action(s)

1. The user selects “Import Profile...” from the File menu.

2. The user selects the correct file to import.

Postcondition(s)

• The profile is imported and thereafter displayed in the list of profiles.








6.19 Export a Profile

ID TC 22Name Export a ProfileRequirement(s) r3.3.5, r7.2, r8.1, and r8.2Description The user exports a profile to a file.Precondition(s)

• There is a profile stored in the software.

Action(s)

1. The user selects “Export Profile...” from the File menu.

2. The user selects the file to export to.

Postcondition(s)

• The selected file contains the profile data.






acceptance test plan - drexel universitydpn52/therawii/acc_plan.pdf · acceptance test plan...

Documents