Test Plan and Cases (TPC)

Mission Science iRobots

Team 07

Jiashuo Li Project Manager, Life Cycle Planner, Developer

Chen Li Requirements Engineer, Software Architect, Developer

Farica Mascarenhas Operational Concept Engineer, IV&V, Quality Analyst

Hanadi Mardah Tester and Software Architect

Sergey Mukhin Prototyper, Developer

Yun Shao Feasibility Analyst, Developer

02/13/15

Version History

Date / Author / Version / Changes made / Rationale /
02/08/06 / PP / 1.0 / ·  Original template for use with LeanMBASE v1.5 / ·  Initial draft for use with LeanMBASE v1.5
11/30/14 / RK / 1.1 / ·  Original for CSCI577; Tailored from ICSM TPC Template
·  Added the work flow of the requirements and how the team proceeded.
·  Added the Test Cases that the team worked and will work in the future. / ·  To fit CS577 course content
02/11/15 / HM / 1.1.1 / ·  Team members are changed and update the test schedule / ·  To fit CS577 course content
02/13/15 / HM / 1.2 / ·  Update test cases and test schedule / ·  To follow LCP and OCD

Table of Contents

Test Plan and Cases (TPC) i

Version History ii

Table of Contents iii

Table of Tables iv

1. Introduction 5

2. Test Strategy and Preparation 6

2.1 Tracing Method 6

2.2 Traceability Matrix 7

3. Test Identification 7

3.1 TC-2.1 Navigation Controls 7

3.2 TC-2.2 Sensor Controls 8

3.3 TC-2.3 Sounds and Lights 10

3.4 TC-2.4 Demo Modes 11

3.5 TC-2.5 Conflict Detection 12

3.6 TC-2.6 Invalid Parameters 13

3.7 TC-2.7 Non-Compiled C Code 14

4. Resources and schedule 15

4.1 Resources 15

4.2 Staffing and Training Needs 15

4.3 Schedule 15

Table of Tables

Table 1_Hardware Preparation 6

Table 2_Software Preparation 6

Table 3_Test Case 001 8

Table 4_Test Case 002 9

Table 5_Test Case 003 10

Table 6_Test Case 004 11

Table 7_Test Case 005 12

Table 8_Test Case 006 13

Table 9_Test Case 007 14

Table 9_Testing Schedule 15

5

TPC_RDCP_SP15_T07_V1.2 Version 1.2.1

1.  Introduction

1.1 Purpose of the TPC

The purpose of this document is to describe the scope, approach, resources, and schedule of testing the Graphical User Interface, software, and requirements for the delivery of the Graphical User Interface to the Mission Science as a part of the Mission Science iRobots.

1.2 Status of the TPC

This version includes test cases and test plans for the project. Section 1 details the purpose, scope and focus of testing for the project. Section 2 details strategy, environment and preparation. Section 3 describes the design of test cases in detail.

1.3 Purpose for Testing

Software testing is a necessary method for finding and mitigating defects, inconsistencies, and ambiguities in documentation and code. The purpose of this Test Plan and Cases document is to capture and track the planned and implemented testing plan and test cases that are used during Team 07 CSCI577 project.

Our test cases will focus on the key aspects of the project, primarily the system functionality, the flow of the components and the user interface. Testing will include execution of portions of the software with inputs designed to solicit specific responses. Those responses will be evaluated to ensure the code is functioning as desired.

1.4 Scope

Testing will commence in the Development phase. The scope of the testing will include verification of the requirements in different stages of the product development iteration. It also includes security aspects of the software components and defect detection strategies.

1.5 Focus

As for program level, unit testing will focus on the methods of UI classes and Translator class to ensure that each individual function and execute as expected.

Module testing will focus on the functionality of each modules, UI, Translator, High-level Program and Emulator, as well as the interaction between these modules.

Functionality testing will focus on the user experience, and collecting feedback from client, undergraduate students and elementary school students.

2.  Test Strategy and Preparation

The project's test strategies with respect to the following options are as follows:

2.1  Hardware Preparation

Table 1_Hardware Preparation

Hardware / Description
iRobot Machine / iRobot Create is an affordable, preassembled mobile robot platform that provides an out-of-box opportunity for educators, students and developers to program behaviors, sounds, movements and add additional electronics.
Microcontroller / It is a microcontroller into which the executable code is loaded.
PC running with Windows / To design and test the drag and drop GUI
Product documentation and user forums / For the users to understand how to program the iRobot
2.2  Software Preparation

Table 2_Software Preparation

Software / Description
Visual Studio 2013 / The software will be used to develop the GUI on windows.
Windows 8.1 / The software will be used as the platform to run the GUI.
WPF based on .Net Framework 4.5 / The software provides the interface to end users to program the iRobot.
Microcontroller Emulator / Self-designed and made platform to execute code for Microcontroller on a PC. Using this platform, we can send byte stream directly from a PC to iRobot and read data from sensor, without the Microcontroller.
WinAVR Compiler / Software used to compile the C program that gets generated from the GUI and load compiled hex program to iRobot.
2.3  Requirements Traceability
2.3.1  Tracing Objective and Method

·  To get the appropriate business workflow, program model, result chain and cost estimation.

·  To discuss with one of the stakeholders about the actual users of the iRobot.

·  To acquire the prototypes for the APTs to be used for each of the operations that iRobot is capable of performing.

·  Team acquired the iRobot Machine to test the development from the client.

·  Team developed the prototype in the more attractive way as suggested by the staff and the faculty along with the client.

·  Team added functionality to the buttons and try to compile the code using the WinAVR tool.

·  Team build the command line program to load generated C code to microcontroller using WinAVR.

2.3.2  Traceability Matrix
OCD / Win Condition / SSAD / Test Case
OC1 / WC-3283 / ATF: Navigation Keys
UCD: 2.1.1 / TC-001, TC-005
OC2 / WC-3285 / ATF: Sensor
UCD: 2.1.2 / TC-002
OC3 / WC-3291 / ATF: Sounds /Light
UCD: 2.1.3 / TC-003
OC4 / WC-3296 / ATF: Loop & Wait Constructs
UCD: 4.1.2.1 / TC-004
OC5 / WC-3305
WC-3304 / ATF: Dome Modes
UCD: 2.1.1 / TC-004

3.  Test Identification

All test cases assume that the user has the Graphical User Interface, the iRobot Machine to test, a PC running windows 8.1 and above and the functional USB ports.

The overall testing process is divided to several parts according module division. Each part consists of unit-testing, beta testing and system testing.

The testing of these modules can be carried out in parallel in order to guarantee the testing efficiency. Once a module is implemented, the unit testing should be first performed on it. After that, beta testing is performed. When all modules are finished, system testing will be performed so that all modules can work with each other correctly.

3.1  TC-2.1 Navigation Controls

Test Case 1 covers the movement of the iRobot. The movement of the iRobot includes the forward, backward and the rotation based on the instructions given by the end user.

3.1.1  Test Level

Software (Interface) Item Level.

3.1.2  Test Class

Unit Testing: After each step the code is being compiled and tested along with the development.

Beta Testing: Each of the function under the Navigation control is being checked by this Test Case. While testing the team is not digging deep into the API's but just the function calls generated by the GUI while the drag and drop functionality.

System Testing: Once the whole of the system is prepared, there will be system testing before delivering the product to the client.

3.1.3  Test Completion Criteria

The iRobot functions as per the given instructions.

3.1.4  Test Case(s)

Table 3_Test Case 001

Test Case Number / TC-001
Test Item / Navigation Controls
Test Priority / Must have
Pre-conditions / Function calls in C coding for forward, backward, left, and right controls on user interface
Post-conditions / Movement of the iRobot as required.
Input Specifications / Drag and Drop Navigation Buttons
Expected Output Specifications / Movement of the iRobot as expected.
Pass/Fail Criteria / Movement of the iRobot as per the parameters specified.
Assumptions and Constraints / Functioning GUI and code able to compile and load onto the micro controller chip
Dependencies / -
Traceability / WC-3283
3.2  TC-2.2 Sensor Controls

Sensor Controls tests if the iRobot is functioned such that it is able to sense the obstacles in front.

3.2.1  Test Level

Software (Interface) Item Level.

3.2.2  Test Class

Unit Testing: After each step the code is being compiled and tested along with the development.

Beta Testing: Each of the function under the Sensor control like the detection of the cliff by the iRobot and the wall in front of the iRobot is being checked by this Test Case. While testing the team is not digging deep into the API's but just the function calls generated by the GUI while the drag and drop functionality.

System Testing: Once the whole of the system is prepared, there will be system testing before delivering the product to the client.

3.2.3  Test Completion Criteria

The iRobot functions as per the given instructions.

3.2.4  Test Cases

Table 4_Test Case 002

Test Case Number / TC-002
Test Item / Sensor Controls
Test Priority / Must have
Pre-conditions / Function Calls in C Code to activate sensors like for cliff detection and obstacle detection on User Interface
Post-conditions / Sensing the obstacles as required.
Input Specifications / Drag and Drop Sensors
Expected Output Specifications / Pop Up window showing an obstacle detected in front.
Pass/Fail Criteria / Pop Up showing the result
Assumptions and Constraints / Functioning GUI and code able to compile and load onto the micro controller chip
Dependencies / -
Traceability / WC-3285
3.3  TC-2.3 Song and LED

Sounds and Lights test if the iRobot is able to help the students compose some sounds as required by the client in the Win Conditions.

3.3.1  Test Level

Software (Interface) Item Level.

3.3.2  Test Class

Unit Testing: After each step the code is being compiled and tested along with the development.

Beta Testing: Each of the function under the Song and LED module is being checked by this Test Case. While testing the team is not digging deep into the API's but just the function calls generated by the GUI while the drag and drop functionality.

System Testing: Once the whole of the system is prepared, there will be system testing before delivering the product to the client.

3.3.3  Test Completion Criteria

The iRobot functions as per the given instructions.

3.3.4  Test Cases

Table 5_Test Case 003

Test Case Number / TC-003
Test Item / Sounds and Lights
Test Priority / Must have
Pre-conditions / Function Calls in C Coding for aggregating sounds and making songs using drag and drop functionality on User Interface
Post-conditions / Composition of the song
Input Specifications / Drag and Drop Sound Buttons
Expected Output Specifications / Playing sounds as expected.
Pass/Fail Criteria / Able to compose a song
Assumptions and Constraints / Functioning GUI and code able to compile and load onto the micro controller chip
Dependencies / -
Traceability / WC-3291
3.4  TC-2.4 Demo Modes

3.4.1 Test Level

Software (Interface) Item Level.

3.4.2 Test Class

Unit Testing: After each step the code is being compiled and tested along with the development.

Beta Testing: iRobot lets us know in which demo mode it is functioning. We have four demo modes for the functioning of the iRobot. While testing the team is not digging deep into the API's but just the function calls generated by the GUI while the drag and drop functionality.

System Testing: Once the whole of the system is prepared, there will be system testing before delivering the product to the client.

3.4.3 Test Completion Criteria

The iRobot functions as per the given instructions.

3.4.4 Test Cases

Table 6_Test Case 004

Test Case Number / TC-004
Test Item / Demo Modes
Test Priority / Must have
Pre-conditions / Able to Drag and Drop different buttons to the WPF and functional testing.
Post-conditions / Functional iRobot in different Demo modes
Input Specifications / -
Expected Output Specifications / Functional iRobot in different Demo modes
Pass/Fail Criteria / All the demo modes functional
Assumptions and Constraints / Functioning GUI and code able to compile and load onto the micro controller chip
Dependencies / -
Traceability / WC-3304, WC-3305
3.5  TC-2.5 Conflict Detection

3.5.1 Test Level

Software (Interface) Item Level.

3.5.2 Test Class

Unit Testing: After each step the code is being compiled and tested along with the development.

Beta Testing: iRobot should be able to detect the conflicting instruction if given by the user while using the Graphical user Interface. While testing the team is not digging deep into the API's but just the function calls generated by the GUI while the drag and drop functionality.

System Testing: Once the whole of the system is prepared, there will be system testing before delivering the product to the client.

3.5.3 Test Completion Criteria

The iRobot functions as per the given instructions.

3.5.4 Test Cases

Table 7_Test Case 005

Test Case Number / TC-005
Test Item / Conflicting Instructions
Test Priority / Must have
Pre-conditions / Conflicts inside/between instructions.
Post-conditions / Results an error in case of conflicting instructions
Input Specifications / Conflicting instructions like forward and backward movement at the same instance
Expected Output Specifications / Pop Up showing conflicting instructions given.
Pass/Fail Criteria / Pass if error pop up at the correct time
Assumptions and Constraints / Functioning GUI and code able to compile and load onto the micro controller chip
Dependencies / -
Traceability / WC-3304, WC-3296
3.6  TC-2.6 Invalid Parameters

3.6.1 Test Level

Software (Interface) Item Level.