Department of Computer Science and Engineering

Document Sample
Department of Computer Science and Engineering Powered By Docstoc
					Senior Design Documentation Library                Test Plan Specification




   Department of Computer Science and Engineering
         The University of Texas at Arlington


                                       Interactive Activity Wall

                                                               Team AWall
                                                             Team Members:
                                                             Alfredo Aguirre
                                                               Sare Ehmann
                                                              Marcus Kearny
                                                               Sarosh Lateef

                                      Last Updated: 16 July 2011 @ 9:35:00 AM
                                      Copy Printed: 16 July 2011 @ 9:35:00 AM




                               Test Plan Specification
Senior Design Documentation Library                                                              Test Plan Specification




                                           Table of Contents
0     References ...........................................................................................................................4
1     Introduction ........................................................................................................................5
      1.1        Product Scope and Overview .............................................................................................. 5
      1.2        Definitions, Acronyms, & Abbreviations ............................................................................ 6
2     Testing Overview ...............................................................................................................8
      2.1        Unit Tests ............................................................................................................................ 8
      2.2        Component Tests ................................................................................................................. 8
      2.3        Integration Tests .................................................................................................................. 8
      2.4        System Verification Tests ................................................................................................... 9
      2.5        Testing Approach ................................................................................................................ 9
      2.5.1      Priority .............................................................................................................................................. 9
      2.5.2      Solution Process .............................................................................................................................. 10
3     Test Items ..........................................................................................................................11
      3.1        Unit Tests .......................................................................................................................... 11
      3.2        Component Tests ............................................................................................................... 16
      3.3        Integration Tests ................................................................................................................ 17
      3.4        Non Functional Tests......................................................................................................... 19
      3.4.1      Hardware Safety Requirements ...................................................................................................... 19
      3.5        System Verification Tests ................................................................................................. 20
      3.5.1      Acceptance Criteria Testing ............................................................................................................ 20
4     Development Risk Issues .................................................................................................21
5     Features to be Tested .......................................................................................................22
6     Features Not to be Tested ................................................................................................24
7     Approach ..........................................................................................................................25
      7.1        Methodology ..................................................................................................................... 25
      7.2        Regression Testing ............................................................................................................ 26
      7.3        Quality Assurance ............................................................................................................. 26
8     Item Pass/Fail Criteria ....................................................................................................27
9     Suspension Criteria and Resumption Requirements ...................................................28
10    Test Deliverables ..............................................................................................................29
11    Remaining Test Tasks......................................................................................................30
12    Schedule ............................................................................................................................31

                                                        Test Plan Specification
Senior Design Documentation Library                                              Test Plan Specification

13    Approvals ..........................................................................................................................32




                                                 Test Plan Specification
Senior Design Documentation Library                  Test Plan Specification


0 References
Team Ninja: Test Plan v1.1

Team TOTs: Test Plan v1.5

Team AWall: SRD v3

Team AWall: DDS v1.5

Team AWall: Project Charter v2

Mr. Michael O’Dell: Example Test Plan Document Content

IEEE Std. 829-1998

IEEE 829 Test Plan Outline




                                 Test Plan Specification
Senior Design Documentation Library                              Test Plan Specification



1 Introduction
1.1 Product Scope and Overview
The goal of this project is to expand, enhance, and modify an existing product known as
an Interactive Activity Wall. The wall is currently designed for a disabled 10-year-old
client, with limited vision and motor skills, but must have an expandable nature to fit
diverse future uses.

Client interaction with the wall is accomplished through several multi-sensory input and
output panels. Activation of these input panels elicits various responses, provided through
the output panels on the device, as determined by an electronic control system (ECS),
residing on a tablet PC. A set of new input and output panels will be added to the existing
set of panels installed in the wall’s framework, which is currently secured to a wall in the
client’s home. All panels are modular in nature, and should be moved or swapped out
with relative ease.

The tablet PC has a touch screen interface, with no keyboard and mouse, to interface with
the user (caregiver) controlling the wall settings. Planned upgrades to the controlling
computer shall allow the caregiver to adjust system settings, control input and output
configuration, and select different activities.




            16 ‘’



           Existing                         Existing      Unused panel /
 16 ‘’     Output
                          New Output
                                            Output        possible future
                                                             output




                           Existing        New Input /       Existing
          New Input
                            Input            output           Input




Figure 1 - The Activity Wall shall be connected to a PC mounted on a wall. The Activity Wall is made
of eight panels. The three new yellow-orange colored panels in the figure above shall be created by
the development team. The green and blue panels in the device represent input and output panels

                                        Test Plan Specification
Senior Design Documentation Library                                 Test Plan Specification

already currently installed in the device. The solid orange panel in the upper right hand side of the
figure shall be left for future expansion




1.2 Definitions, Acronyms, & Abbreviations

                         Activity:   A mode of the Activity Wall in which the client, when
                                     triggering an input panel, shall receive an interactive response
                                     from the system via an output panel with the goal of
                                     entertaining and engaging the client. The response will vary
                                     depending on the activity selected – for instance Piano mode
                                     triggers an audio response.

                    Activity Wall:   Wish with Wings Activity Wall which consists of a grid framework
                                     and input/output panels.

                   Administrator:    The system administrator/updater will maintain and update the
                                     computer control system. Individuals that can be considered
                                     administrators include but are not limited to UTA student members
                                     of a senior design team, and UTA faculty.



                    Breeze Panel:    One of the seven subcomponents on the Activity Wall, an output
                                     panel that shall generate a gust of air as an output response.



                    Button Panel:    One of the seven subcomponents on the Activity Wall, an input
                                     panel that consists of four colored buttons.

                       Caregiver:    Daniel’s mother, nurse, or sister. Caregivers will control the
                                     Activity Wall via an Electronic Control System running on a tablet
                                     PC.


                           Client:   Daniel Torres, a disabled eleven year old with the physical motor
                                     skills and mental capacity of a ten month old; he shall be the
                                     primary user of the wall.


       Electronic Control System     An application run on a PC that interfaces with the panels and the
                          (ECS):     caregiver.

    Force/Motion Sensing (FMS)       One of the seven subcomponents on the Activity Wall, an input
                         Panel:      panel, possessing a device meant to be manipulated by the client
                                     with the purpose of measuring force and speed, such as a lever.




                                          Test Plan Specification
Senior Design Documentation Library                              Test Plan Specification




              Input Panel:    One of the seven subcomponents on the Activity Wall, which
                              should take an input through its physical interface (see figure in
                              Section 1.7).

               Light Panel:   One of the seven subcomponents on the Activity Wall, an output
                              panel containing a series of lights that illuminate based on client
                              input.


             Output Panel:    One of the seven subcomponents on the Activity Wall, which
                              should provide an output through its physical interface (see figure
                              in Section 1.7).

                    Panel:    One of the seven subcomponents on the Activity Wall. One of these
                              panels shall be placeholder which shall be designed and provided
                              by a third party through the Wish for Wings Foundation (see figure
                              in Section 1.7).


            Speaker Panel:    One of the seven subcomponents on the Activity Wall, an output
                              panel containing a speaker that plays audio clips based on client
                              input.

                 Tablet PC    The computer currently installed in the client’s home running the
                              ECS and connected to all panels in the framework via USB cabling.


             Tactile Panel:   One of the seven subcomponents on the Activity Wall, a Dual-
                              Purpose panel that will receive input, and will deliver output via
                              several components each possessing unique tactile textures and
                              tactile output mechanisms.

         Training Program:    Software accessible via an application which shall run on the tablet
                              PC that has a specific learning objective meant to actively engage
                              the client.


                Variability   A range reflecting the amount of variation an output should
                              express.


                     Wall:    See Activity Wall.


              Wheel Panel:    One of the seven subcomponents on the Activity Wall, an input
                              panel containing a steering wheel.



                                      Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification



2 Testing Overview
This document details the plan Team AWall has agreed to follow to acceptably test their
project, the Interactive Activity Wall. Since this project is made of hardware and software
components, the testing of both will be specified in the following sections.

The hardware items to be tested will be: buttons panel, wheel panel, breeze panel, tactile
panel, FMS panel, and applicable circuits. The software item to be tested will be the
Activity Wall Software. The features of the software to be tested will be: activity
function, activity selection, training function, training selection, reporting, and settings
management.

All of the above items and features will be thoroughly tested through a variety of testing
methodologies, including but not limited to: unit, component, integration, and system
verification testing.

2.1 Unit Tests
For software testing each method of the subsystems will be a unit. Each unit will be
tested as a black box. Controlled input will be given to the function and the output will
be compared with the expected outputs. Each method outlined in the DDS will be tested
as it is created; the testing will be performed by the developer of the module.

For hardware testing each function of the hardware subsystem will be tested separately.
The hardware will be given the inputs required to fulfill the expected behavior. The
hardware behavior will be graded on whether it is performing as required.

2.2 Component Tests
Each component test will be executed at the subsystem level. The subsystem is a group
of units outlined in the ADS. The subsystem will be treated as a black box. The
subsystems will be given controlled inputs and the output will be recorded to compare
them with the expected outcomes. Each subsystem described in the ADS will be tested
separately. Component test will be performed collaboratively by two team members.

2.3 Integration Tests
Integration tests will be performed to test functionality over multiple subsystems.
Integration testing will begin when all necessary components have been tested for a
particular integration test. Integration tests will be performed in the senior design lab as
much as possible, though final testing will occur on-site at the client’s home. Testing
will be performed collaboratively by at least two team members.




                                     Test Plan Specification
Senior Design Documentation Library                          Test Plan Specification


2.4 System Verification Tests
The tests performed after all of the partial testing has been completed are considered
System Verification Tests. The use cases specified in the SRD for the project will be
tested. Additionally, each requirement from the Acceptance Criteria in the SRD will be
tested separately. These tests will assure the functionality of the whole project.

2.5 Testing Approach
Testing will encompass exploratory methods to discover bugs, and reparative methods to
address and eliminate the bugs. Exploratory measures will include the testing listed in
the previous sections: unit testing, component testing, integration testing, and system
verification testing.

Once a bug is found, reparative measures will be taken. First the bug will be assessed a
priority then, based on state of the project, severity of the bug, availability of developers,
and the discretion of the appropriate lead, the bug will be addressed in a solution process,
delineated below.

2.5.1 Priority
Once a bug is found and entered into the Bug List, it will be assessed a priority by the
quality lead or the engineer of discovery. The priorities will be:



       CRITICAL                The system will not pass acceptance if the bug remains

       URGENT                  The bug impairs several components of the
                                     system

       HIGH                    The bug impairs the function of its component

       MEDIUM                  The bug is leads to inconsistent functioning of the
                                     component

       LOW                     The bug does not affect functionality



Bugs with Critical priority shall be addressed first, and so on down the priority list.




                                      Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification


2.5.2 Solution Process
The following delineates the steps that are necessary once a bug has been found.
   1. Notify appropriate Lead – Notification of the hardware or software lead is
      essential to keep them informed of the overall health of the system. The lead and
      engineer of discovery must assess the priority of the bug and update the BugList.
   2. Collaborate – The engineer of discovery must collaborate with the creator of the
      module, or in the case that the creator is the same as the discoverer at least one
      other team member, in order to ascertain the problem. The team members will fix
      the bug if possible, and note any changes in priority of the bug upon further
      investigation.
   3. Notify appropriate Lead – The appropriate lead and quality lead must be
      informed of the status of the bug after the initial troubleshooting. This will
      include the state of resolution and any modules affected.
   4. Reassess & Reallocate resources – If the priority of the bug has changed, or the
      engineers are unable to resolve the bug, reassessment of the situation by the lead
      will be necessary. The lead may reallocate resources or postpone resolution of the
      bug as time and availability allows.
   5. Test – Once the bug is resolved, the resolving engineers must thoroughly test the
      components changed, following all quality management procedures.
   6. Inform Quality Lead – The quality lead must be informed of the status of
      testing, and allocate testing resources to ensure components tested prior to the
      resolution of the bug are adequately retested and no further bugs are introduced.



The engineers tasked with addressing the bug may use any method at his disposal. Some
of these will include:
      Code reviews
      Isolation of modules to pinpoint buggy modules
      Referencing the architecture and design specifications to ensure proper logical
       function




                                    Test Plan Specification
Senior Design Documentation Library                            Test Plan Specification



3 Test Items
Each of Team AWall’s tests will fall into one of four categories: Unit, Component,
Integration, and System Verification tests. Due to time constraints, Team AWall may not
be able to perform all tests as outlined in this document. Also, AWall may add new tests
as necessary. However, AWall will test the Activity Wall’s software and hardware
thoroughly enough to ensure that the final product works safely and properly with few
bugs.

3.1        Unit Tests
Unit Tests cover the most elementary elements in the system, such as the buttons panel,
lights panel, GUI menus, code modules, etc. Each developer will test his own code and
hardware to ensure unit integrity. When the developer feels that the unit is satisfactory,
the team will proceed to perform the more detailed tests described below.

Subsystem      Units(Functions)    Priority         Input                      Output


Options GUI startGUI               HIGH       N/A                   Starts all Options GUIS and
                                                                    system home screen


Options GUI addInputGUI            HIGH       List<InputGUI>        InputGUIs are added to the
                                                                    options GUI


Options GUI addOutputGUI           HIGH       List<OutputGUI>       OutputGUIs are added to the
                                                                    options GUI


Options GUI addFiles               LOW        FileInfo object with Updates Data layer with new
                                              location of file     file


Options GUI updatePanelMap         HIGH       Panel settings        List<Partial Map> containing
                                                                    new activity information


Options GUI displayFiles           MEDIUM Type of file              List<FileInfo> containing
                                                                    references to all file types
                                                                    requested; display of the files
                                                                    on the screen


Options GUI startTraining          HIGH       N/A                   Gathers training feature, input
                                                                    panel, output panel, and theme
                                                                    choice from user and sends the
                                                                    information to the Training
                                                                    Manager



                                    Test Plan Specification
Senior Design Documentation Library                       Test Plan Specification



Options GUI advanceTrainingSelection HIGH   N/A                Sends the advance command
                                                               to the Training Manager


Options GUI endTraining             HIGH    N/A                Sends the end command to the
                                                               Training Manager


Input GUI    addOptions             HIGH    N/A                A list of input panel options
                                                               stored inside the InputGUI
                                                               object, representing the input
                                                               avenues of that panel


Output GUI   updateConfiguration    LOW     --                 --


Connection   establishConnections   HIGH    N/A                A list of Input Listeners,
Manager                                                        Output Listeners & Logic,
                                                               Activity Logics, Input GUIs,
                                                               and Output GUIs


Input        Constructor            HIGH    N/A                This will contain four tests –
Listener                                                       one for each of the four input
                                                               panels. Each input listener
                                                               will start up the method for
                                                               listening to the hardware.


Input        readPanel              HIGH    N/A                This will contain four tests –
Listener                                                       one for each of the four input
                                                               panels. Each readPanel will
                                                               produce an event with the
                                                               current state of the input
                                                               panel.


Input        fire                   HIGH    Msg object         Fires an event
Listener


Activity     Constructor            HIGH    N/A                Creates a PanelMap object if
Logic                                                          none exists


Activity     onChangeHandler        HIGH    Msg input object   This will contain four tests –
Logic                                                          one for each of the four output
                                                               panels. Each activity logic
                                                               will transform the Msg input
                                                               object into an Msg output
                                                               object containing the correct
                                                               output option and a variability.


Activity     addActivity            HIGH    List<PartialMap>   Adds each Partial Map item to
Logic                                                          the Panel Map object

                                    Test Plan Specification
Senior Design Documentation Library                           Test Plan Specification



Activity     purgeActivity        HIGH       String containing        Removes each Partial Map
Logic                                        the panel ID             item containing that panel ID
                                                                      as an input panel


Activity     peekActivity         MEDIUM String containing            A string containing the
Logic                                    the panel ID                 formatted textual output of all
                                                                      Panel Map connections for
                                                                      that input panel


Activity     processVariability   HIGH       N/A                      This will contain four tests –
Logic                                                                 one for each of the four
                                                                      activity logics. The
                                                                      processVariability method will
                                                                      produce a number between 0
                                                                      and 255 that indicates the
                                                                      amount of output to be
                                                                      produced given the current
                                                                      and historic states of the input
                                                                      panel.


Output       Constructor          HIGH       N/A                      This will contain four tests –
Listener &                                                            one for each of the four output
Logic                                                                 panels. Each constructor will
                                                                      open the port to the output
                                                                      panel and initialize the list of
                                                                      output options for that panel.


Output       onChangeHandler      HIGH       Msg output object        This will contain four test –
Listener &                                                            one for each of the four output
Logic                                                                 panels. Each
                                                                      onChangeHandler will
                                                                      transform an output Msg
                                                                      object into hardware specific
                                                                      instructions for output and
                                                                      implement the variability.


Output       updateConfig         LOW        A configuration          This will contain four tests –
Listener &                                   value                    one for each of the four output
Logic                                                                 panels. Each updateConfig
                                                                      will change the configuration
                                                                      options for that panel (base
                                                                      volume, duration of output, or
                                                                      brightness of lights).


Admin        addFile              MEDIUM FileInfo containing the Produces a copy of the file in
Manager                                  path of the object,     the Data layer at the specified
                                         Directory containing    Directory
                                             the destination of the
                                             object



                                   Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification



Admin      deleteFile             LOW      FileInfo containing    Removes the file from the
Manager                                    the path of the file   Data layer


Admin      viewLog                LOW      FileInfo containing    A string containing the text of
Manager                                    the path of the log    the log.


Admin      listDirectory          MEDIUM Directory object         FileInfo[] containing
Manager                                                           references to all files in the
                                                                  directory


Activity   startActivityManager   HIGH     List<ActivityLogic> Initializes Activity Logic list,
Manager                                                        starts training manager


Activity   updatePanelMap         HIGH     List<PartialMap>       Removes all old Partial Maps
Manager                                                           in the Panel Map for the input
                                                                  panel, and adds the new
                                                                  Partial Maps in their place.


Activity   loadActivity           MEDIUM FileInfo                 List<PartialMap>
Manager


Activity   saveActivity           LOW      String containing      A saved file in the Data layer
Manager                                    the panel ID           containing current activity
                                                                  information


Activity   deleteActivity         LOW      FileInfo               Removes the file from the
Manager                                                           Data Layer


Activity   currentStateRequest    HIGH     String containing      A string containing the
Manager                                    the panel ID           formatted textual output of all
                                                                  Panel Map connections for
                                                                  that input panel


Training   startTraining          HIGH     N/A                    A Training Map (2D array of
Manager                                                           strings) containing a listing of
                                                                  all possible training modules
                                                                  currently installed


Training   getFeatures            HIGH     N/A                    Set<String> containing all
Manager                                                           features in the Training Map


Training   getInputOptions        HIGH     String containing      Set<String> containing all
Manager                                    feature name           input panels in the Training
                                                                  Map that can train the given
                                                                  feature



                                  Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification



Training      getOutputOptions   HIGH     String containing      Set<String> containing all
Manager                                   feature name, String   output panels in the Training
                                          containing input       Map that can train the given
                                          panel ID               feature on the given input
                                                                 panel


Training      getTrainingList    HIGH     String containing      List<FileInfo> containing all
Manager                                   feature name, String   training modules currently
                                          containing input       available to train on the given
                                          panel ID, String       options.
                                          containing output
                                          panel ID


Training      getThemes          MEDIUM String containing        A list of Strings containing
Manager                                 output panel ID          theme names that can be
                                                                 played on the given output
                                                                 panel


Training      next               HIGH     N/A                    A GUI object containing the
Manager                                                          training command, and the
                                                                 “Next” and “Stop” options


Training      stop               HIGH     N/A                    Ceases training program, frees
Manager                                                          all activity associations for the
                                                                 input panel being trained


Input Panel   Button Panel       LOW      Button pressed         Correct byte code for that
                                                                 color button produced


Input Panel   Wheel Panel        HIGH     Wheel turned           Correct byte code for the
                                                                 position of the wheel produced


Input Panel   FMS Panel          HIGH     Lever pulled           Correct byte code for the
                                                                 position of the lever produced


Input Panel   Tactile Panel      HIGH     Surface touched        Correct byte code for that
                                                                 tactile component produced


Output Panel Lights Panel        LOW      Sequence of byte       Lights operate in the expected
                                          codes                  sequence/pattern


Output Panel Breeze Panel        LOW      On/Off command         The fan turns on or off


Output Panel Tactile Panel       HIGH     Byte code              The correct tactile output
                                                                 motor is turned on.



                                 Test Plan Specification
Senior Design Documentation Library                           Test Plan Specification


3.2 Component Tests
A component test is composed of two or more units, and traverses part of a use case. The
units will be related to each other and can be tested independently of others.

Subsystem Priority                   Input                           Expected Result


Connection     HIGH   N/A                                 All subsystems operational and initialized
Manager

Input Panels   HIGH   Input is provided to the input      Panel state is communicated to Input
                      avenues of each panel               Listener

Input          HIGH   Panel state from input panel        Input Msg object is created with panel
Listener                                                  state

Activity       HIGH   Input Msg object with panel state   Output Msg object with output option and
Logic                                                     variability

Output         HIGH   Output Msg object; configuration    Output command to hardware;
Listener &            change request                      Implementation of variability;
Logic                                                     Configuration update

Output         HIGH   Output command                      Execution of that command (sound, light
Panels                                                    pattern, breeze on/off, tactile component
                                                          on/off)

GUI            HIGH   Inputs from the user                Activity state changes; Data layer state
                                                          changes

Admin          LOW    State change commands; Data         State changes in Data produced; Files
Manager               requests                            from Data retrieved

Activity       HIGH   State change commands; Data         State changes in the Panel Map produced;
Manager               storage/retrieval requests          Files stored to Data/removed from Data

Training       HIGH   State change commands;              Signal over the parallel port
Manager




                                       Test Plan Specification
Senior Design Documentation Library                             Test Plan Specification




3.3 Integration Tests
An integration test is composed of two or more components and covers the interfaces
between subsystems depicted in Team AWall’s Architecture Design Specifications. The
components will be related to each other and can be tested independently of other
component connections.

    Subsystem              Subsystem         Priority               Expected Result
     Source                Destination


Input Panel         Input Listener           HIGH       An input on any of the four input panels
                                                        produces an input Msg object in Input
                                                        Listener.

Input Listener      Activity Logic           HIGH       An input Msg object from Input Listener
                                                        produces an output Msg object, containing
                                                        output panel information and variability. This
                                                        object will contain information for all output
                                                        panels connected to the input panel as
                                                        detailed in the Panel Map.

Activity Logic      Output Listener & Logic HIGH        An output Msg object from Activity Logic
                                                        produces an output request to all physical
                                                        output panels connected to the input panel as
                                                        detailed in the Panel Map.

Output Listener &   Output Panel             HIGH       An output request from Output Listener &
Logic                                                   Logic produces a physical effect in any of the
                                                        four output panels.

Activity Manager    Activity Logic           HIGH       Change requests from Activity Manager
                                                        modify the Panel Map in Activity Logic
                                                        correctly.

GUI                 Activity Manager         HIGH       Input from the GUI correctly configures the
                                                        Panel Map to a particular activity setting.

GUI                 Data                     MEDIUM Input from the GUI correctly updates the Data
                                                    layer with saving or removing activity-related
                                                    files. Added files will be visible to the
                                                    system thereafter.


GUI                 Training Manager         HIGH       Input from the GUI correctly starts,
                                                        progresses, and stops a training module.



                                         Test Plan Specification
Senior Design Documentation Library                     Test Plan Specification




Training Manager   GUI                 HIGH     GUI components from the Training Manager
                                                allow for the user to select a training module
                                                based on guided input.


GUI                Admin Manager       LOW      Input from the GUI correctly change system
                                                settings.


GUI                Data                LOW      Input from the GUI correctly updates the Data
                                                layer with file additions/deletions. Added
                                                files will be visible to the system thereafter.

Input Panel        Activity            HIGH     An input to any of the four input panels
                                                results in output requests to the correct output
                                                panel hardware.

Activity           Output Panel        HIGH     An input panel state from any of the four
                                                input panels results in the correct output panel
                                                performance.

GUI                Activity            HIGH     Input to the GUI correctly updates the activity
                                                or training.




                                   Test Plan Specification
Senior Design Documentation Library                                 Test Plan Specification


3.4 Non Functional Tests
3.4.1 Hardware Safety Requirements
Hardware Priority                      Input                              Expected Result


All Panels    HIGH      Leaning/pressing on the panel,          The panel shall remain in place and not
                        pulling on the panel                    dislodge or reposition

Button Panel LOW        Pulling on buttons, pressing on         The buttons shall remain firmly affixed
                        buttons                                 and not create any openings that may
                                                                harm the client

Wheel Panel   HIGH      Turning wheel quickly, pulling          The wheel shall remain firmly affixed
                        wheel away from panel, pulling          and not create any openings that may
                        wheel down from panel (with             harm the client
                        expected force)

Tactile Panel HIGH      Pressing the components, leaning on The tactile surfaces shall remain firmly
(Input)                 the components, pulling on the      affixed to the panel and not create any
                        surface                             openings that may harm the client.
                                                            Additionally, the play in the surface
                                                            fabric will not allow for the grasping and
                                                            pulling of the fabric or the fabric will be
                                                            strong enough to withstand tears.

FMS Panel     HIGH      Pulling the lever, leaning on the       The lever shall remain firmly affixed to
                        lever in the downward position,         the panel and not create any openings that
                        turning the lever’s manual resistance   may harm the client. Additionally, the
                        bar                                     lever and manual resistance bar must be
                                                                client-safe.

Tactile Panel HIGH      Pressing the components, leaning on The tactile motion motors shall not
(Output)                the components                      become dislodged or loose, and the
                                                            motion shall be client-safe.

Breeze Panel LOW        Pressing/leaning on the grate/mesh.     The motion of the fan must be obscured
                                                                from the client by a grate or strong mesh
                                                                which remains firmly in place under
                                                                duress.

Framework     MEDIUM Pulling on edging, striking edging         The edging installed on the edges of the
                                                                framework shall remain firmly in place
                                                                under duress




                                        Test Plan Specification
Senior Design Documentation Library                                  Test Plan Specification



3.5 System Verification Tests
A system verification test is composed of one or more integration tests and covers the top
priority requirements as outlined in the System Requirements Document. This verifies
that the system was built right as opposed to system validation tests which test if the right
system was built.

Please refer to the SRD §17 for more details.

Example of System Verification Test template:

      Per §17 of SRD, a “Top Priority Requirement” would be §4.4.12: Training
       Module

               Requirement as Stated in SRD: The product shall contain a training module.

            Pass if: Activity Wall software contains a functioning training module that
             can be activated, run, and stopped.

               Fail if: Activity Wall software does not contain a functioning training
                module.

3.5.1 Acceptance Criteria Testing
The system will be verified by also testing against the acceptance criteria outlined in the
SRD. Acceptance criteria are located in §19 of the SRD.

Example of Acceptance Criteria Test template:

      An Acceptance Criteria as Stated in SRD: The dual-purpose panel shall receive inputs as
       well as send outputs, to itself, or to other output panels through tactile components.

            Pass if: The dual-purpose panel can be configured to send outputs to itself
             or other panels; the dual-purpose panel can successfully process client
             input; the dual-purpose panel can successfully process output commands.




                                          Test Plan Specification
Senior Design Documentation Library                      Test Plan Specification



4 Development Risk Issues
The list below includes remaining risks to Team AWall’s development process.

      Friction between developers and client’s caregivers

          o Changes in requirements by caregiver have led to late-stage changes in the
            project, and further requests to change requirements may result in failure
            to deliver the system.

      Poor framework construction

          o The panels in the wall are not swappable as intended; some can fit into
            only certain spots in the wall. This will limit Team AWall’s ability to
            fabricate new panels for the wall, and will limit the positioning of new and
            old panels in the wall.

      Buggy hardware components

          o The wheel panel must be rebuilt due to poor construction.

          o The buttons panel is producing unexpected results, and may require
            additional effort or rebuilding to produce valid inputs.

      Incompatible drivers for microcontroller

          o The microcontroller Team AWall plans to use for the tactile and FMS
            panels may not have drivers compatible with Windows Vista. Other
            solutions may need to be explored.

      Software not fully implemented

          o The software previously written is tightly integrated with the relational
            database that the current wall uses. Eliminating the relational database has
            created a great deal of additional effort required on the part of Team
            AWall to ensure functionality remains in the system. Implementation of
            new features and redevelopment of old features threatens the completeness
            of the software efforts.

      Panel hardware and firmware not implemented in time

          o With the reprioritization of requirements and the additional work created
            by the buggy construction mentioned above, there is more panel hardware
            and firmware to create in the same amount of time.

      Developer exhaustion

                                   Test Plan Specification
Senior Design Documentation Library                            Test Plan Specification



5 Features to be Tested
The features to be tested below are presented from the perspective of the Client, the
Administrator or the Caregiver. For each subsystem listed below, the appropriate system
will be tested in a typical use case to demonstrate that the feature works as intended. See
section 23.2 of the Systems Requirement Document for a description of use cases that
cover much of the intended functionality.

The components/modules being tested refer to the components/modules mentioned in
Section 3 Quality Assurance of Team AWall’s DDS document. The risk levels are Low,
Medium, and High.

The Activity Wall features being tested are:


Feature                                               Risk Level    Component being
                                                                    Tested
System is turned on                                   HIGH             Connection
                                                                        Manager
Input is given through Input Panel                    LOW              Input Panels
System settings are changed by caregiver              LOW              GUI
                                                                       Admin Manager
Panel settings are changed by caregiver               LOW              GUI
                                                                       Output Listener &
                                                                        Logic
Audio files are added by caregiver                    LOW              GUI
                                                                       Admin Manager
Audio files are removed by caregiver                  LOW              GUI
                                                                       Admin Manager
Activities are created by caregiver by associating    HIGH             GUI
input panels with output panels and configuring                        Activity Manager
output options                                                         Activity Logic
Activities are saved by caregiver                     MEDIUM           GUI
                                                                       Activity Manager
Activities are loaded by caregiver                    HIGH             GUI
                                                                       Activity Manager
Training module is selected by caregiver              HIGH             GUI
                                                                       Training Manager
Training module is started by caregiver               HIGH             GUI
                                                                       Training Manager
Training module is advanced by caregiver              HIGH             GUI
                                                                       Training Manager
Training module is stopped by caregiver               HIGH             GUI
                                                                       Training Manager

                                          Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification

Error logs are viewed by the administrator         LOW              GUI
                                                                    Admin Manager
Error logs are deleted by the administrator        LOW              GUI
                                                                    Admin Manager
Input to a panel produces varying output           HIGH             Input Panel
                                                                    Input Listener
                                                                    Activity Logic
                                                                    Output Listener &
                                                                     Logic
                                                                    Output Panel




                                       Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification



6 Features Not to be Tested
Team AWall reserves the right to not test, or completely test, components listed in the
“Second Priority Requirements” and “Third Priority Requirements”, as listed in the SRD
due to time constraints and/or budget constraints. This decision is based on the fact that
AWall also reserves the right to limit implementation to only “Top Priority
Requirements” if the implementation deadline approaches with the product not being
complete. Based on the current situation, the Interactive Fun Wall will not contain
implementation of the add/remove panel features and the kill switch.

Team AWall also will not test the following requirements from Section 10.2 (Safety
Requirements) of the System Requirements Document:
                   The voltage supplied not exceed 12V DC
                   Grounded metal
                   Ground Fault Interrupters (GFI)
                   Fuse protected circuits
                   Structurally sound grid framework
                   Safe electrical system

The above listed electrical requirements will not be tested as they will be accounted for in
the design of the system, or should have been addressed by the contractors who built the
wall and the electricians who ran power to it last semester.

Team AWall will also not test features from the previous implementation of the wall, as
outlined in section 4.2 in the System Requirements Document.




                                     Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification



7 Approach
Team AWall will use this document, the use cases in the System Requirements
Document (Section 23 Use Cases), and the quality assurance guidelines in the System
Requirements Document (Section 9 Quality Assurance) to perform testing. As previously
mentioned, AWall may not be able to complete all tests thoroughly due to time
constraints and may add tests if necessary.

7.1 Methodology
Developers will begin by performing unit testing as each unit is developed. Each
developer is responsible for testing and verifying that his unit works reliably and
documenting any bugs found. As soon as enough units are completed and tested, AWall
will move on to component testing. As soon as enough components are completed and
tested, AWall will proceed to integration testing. These three phases will overlap,
because each test is dependent on different units and components, and AWall would like
to perform testing as efficiently and expediently as possible. Finally, Team AWall will
perform system tests to verify that the system as a whole performs correctly.

It is preferable that there be no bugs at the unit level. Bugs at lower levels can snowball
as the project reaches the higher levels of testing/integration, and debugging will become
much more difficult.

Bugs found at any level will be recorded and handled in the manner described in Team
AWall’s Project Charter document.




                                     Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification


7.2 Regression Testing
Whenever a bug is fixed, it is necessary to perform regression tests. These tests will
verify that the bug fix did not break any other components or units. Regression tests are
not actually new tests. This process is simply performing the previously performed unit,
component, integration, and system tests. If more bugs are found, they will need to be
fixed and the regression tests will need to be restarted. This will continue until no bugs
are found. At that time, regular testing will resume until more bugs are found.



7.3 Quality Assurance
Team AWall will attempt to produce a final product with as few bugs as possible. In
addition, the system should try to catch and handle as many errors as possible. If the
system can proceed despite the errors, it should do so, and only stop if absolutely
necessary. It is assumed that the Caregiver is not technologically inclined and the
Administrator cannot go to the site immediately. Therefore, the system should be as self
sufficient as possible.




                                     Test Plan Specification
Senior Design Documentation Library                        Test Plan Specification



8 Item Pass/Fail Criteria
Unit and/or component tests will be evaluated based on the expected functionality of the
item(s) under observation.

A “Success” result will be received if the unit or component operates within its expected
range.

A “Failure” result will be received if the unit or component does not function as
expected.

Integration tests will be evaluated based on success or failure of the interaction between
the components and the expected functionality of the combination of components
included in the test.

A “Success” result will be received if component interaction is successful and the
combination of components operates within its expected range.

A “Failure” result will be received if component interaction fails or the combination of
components does not function as expected.

System release tests will be evaluated based on the system’s ability to comply with its
requirements.

A “Success” result will be received if the system meets the requirement(s) under
observation.

A “Failure” result will be received if the system fails to meet the requirement(s) under
observation.

Performance expectations for individual test cases may vary.




                                     Test Plan Specification
Senior Design Documentation Library                         Test Plan Specification



9 Suspension Criteria and Resumption Requirements
A test will be suspended if no explainable output or results of the test can be observed, in
which case the test will have little value for continuation. If errors are encountered on an
intermittent basis and constructive observations regarding the unit or component being
examined can still be made, testing may continue or may be delayed pending repairs at
the discretion of the tester.

Testing of a failed component may be attempted before corrections are made if the tester
believes different scenarios for testing, such as different operation modes or other
parameter sets, may warrant testing.

Suspended tests should resume after the errors are diagnosed and corrected.




                                     Test Plan Specification
       Senior Design Documentation Library                                     Test Plan Specification



       10 Test Deliverables
       Two test case deliverables will be provided including a test case table and this system test
       plan document. The test case table will include a test case ID, objective of the test, list of
       units and/or components included in the test case, instructions for running the test or a
       referral to instructions elsewhere, scheduled test date, actual test date, tester(s) running
       the test, status of the test, and results of running the test case will be maintained and
       stored on Google Docs. Entries for component/unit tests as well as system integration
       tests will be stored. A printout and an electronic copy of the test case table will be
       provided.



Test     Objective       Unit(s) /          Instructions          Scheduled   Actual Test   Tester(s)    Status    Result
case                   Component(s)                               Test Date      Date
 ID

23.2     Test FMS      Panel layer     Panel should send          11/22       11/23         Alfredo,    Complete   Success
         panel         software,       positional information                               Marcus
         variability   FMS Listener,   to the listener, which
         check         FMS Activity    will forward state to
                       Logic           activity logic. Activity
                                       logic should produce a
                                       higher variability as
                                       the lever is pulled
                                       further down




       This system test plan document will also be provided for reference.




                                                     Test Plan Specification
Senior Design Documentation Library                         Test Plan Specification



11 Remaining Test Tasks
All intended test cases, whether complete or incomplete, will be listed in the test case
table. The results column of the table will serve as an indicator for which test tasks are
complete, which ones failed, and which ones have not been tested, if any.




                                     Test Plan Specification
Senior Design Documentation Library                       Test Plan Specification



12 Schedule
The testing of the Activity Wall will begin on November 1st and end on December 2nd.
Below details the specific milestones that will be completed during this testing period:

November 1st – Unit testing begins

November 23rd – Unit testing is complete

November 23rd – Component testing begins

November 27th – Component testing is complete

November 25th – Integration begins

December 2nd – Integration testing is complete

November 27th - System Verification testing begins

December 2nd - System Verification testing is complete




                                     Test Plan Specification
Senior Design Documentation Library                Test Plan Specification



13 Approvals


____________________________________ _______________
Alfredo Aguirre (Software Lead)            Date


____________________________________ _______________
Sare Ehmann (Quality Assurance Lead)       Date


____________________________________ _______________
Marcus Kearny (Team/Hardware Lead)         Date


____________________________________ _______________
Sarosh Lateef (Risk Manager)               Date



____________________________________ _______________
Mike O’Dell (Project Manager)              Date




                               Test Plan Specification

				
DOCUMENT INFO