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
04/14/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.1.2 / · Update test cases and test schedule / · To follow LCP and OCD
03/11/15 / FM / 1.1.3 / · Added unit tests / · To provide details for each test
03/14/15 / FM / 1.1.4 / · Updated unit tests and added Invalid Instruction Test case / · To provide detailed information for test cases
03/15/15 / FM / 1.1.5 / · Added a separate section for Unit Test cases / · To provide detailed information for test cases
03/17/15 / HM / 1.1.6 / · Added more unit test for validator class and Instructor class / · To provide detailed information for test cases
04/01/15 / HM / 1.1.7 / · Modify unit tests according to changes in some class’s methods
· Add new unit tests for HL program / · To make sure the tests are passed
04/05/15 / HM / 1.1.8 / · Add new unit tests for HL program and Program View Model / · To provide detailed information for test cases
04/14/15 / HM / 1.2 / · Modify and add new unit tests to translator and instruction / · To make sure the tests are passed
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 Hardware Preparation 6
2.2 Software Preparation 6
2.3 Requirements Traceability 6
3. Test Identification 7
3.1 TC-2.1 Navigation 8
3.2 TC-2.2 Sensor 9
3.3 TC-2.3 Song and LED 10
3.4 TC-2.4 Demo Modes 11
3.5 TC-2.5 Conflict Detection 12
3.6 TC-2.6 Invalid Instruction 13
3.7 TC-2.7 Invalid Parameters 14
3.8 TC-2.8 Non-Compiled C Code 15
4. Unit Test Cases 17
5. Resources and schedule 20
5.1 Resources 20
5.2 Staffing and Training Needs 20
5.3 Schedule 20
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 20
Table 10_Test Case 008 22
Table 11_Testing Schedule 24
20
TPC_TRR_SP15_T07_V1.2 Version 1.2
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 iRobot.
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 module, 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 / DescriptioniRobot 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 / DescriptionVisual 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 CaseOC1 / 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
This test case tests the movement of the iRobot namely forward, backward and rotation instructions
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-001Test Item / Navigation
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
This test case tests if the iRobot is able to sense the obstacles in its path.
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-002Test Item / Sensor
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
This test case tests if the iRobot is able to 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-003Test 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
This test case tests if the pre-defined demo modes function as expected so that first-time users can understand how the iRobot works.
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-004Test 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
This test case tests if the GUI provides a message indicating a problem with conflicting instructions.
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.