Software Test Plan

Prepared by Nicholas Otter and Jordan Leithart

Version beta-0.8

TABLE OF CONTENTS

• Change Log
• Introduction
  • Objectives
  • References
• Test Items
• Environmental Requirements
  • Hardware
  • Software
  • Tools
• Features To Be Tested
• Features Not To Be Tested
• Approach
  • Unit Testing
  • Integration Testing
  • Regression Testing
  • Acceptance Testing
• Pass / Fail Criteria
  • Pass Criteria
  • Fail Criteria
• Testing Process
  • Test Deliverables
  • Testing Schedule

Change Log

Git History

Date	Person	Change
2013-09-20	Nick Otter	Adding Document Outline
2013-09-21	Nick Otter	Adding Initial Content
2013-09-23	Nick Otter	Adding Change Log, correcting Test Type Table
2013-09-23	Nick Otter	Adding content for Environmental Requirements -> Hardware, Software, tools
2013-09-23	Nick Otter	adding links to the table of contents

Introduction

###Objectives

The objective of this Software Testing Plan is to assure an acceptable level of quality to each release of KickShot for Android and to assure improvements don't cause bugs for existing features.

###References

• Software Requirements Specification
• Software Design Document

Test Items

KickShot for Android can be split into three modules: navigation items, game logic, and views. Each will be tested separately before final cohesive testing.

Test Item	Description
Navigation Items	Using buttons and menu items will allow the user to navigate throughout the application quickly and easily. Functionality will be tested with Robotium.
Game Logic	Allow the user to play a game of KickShot Junior. This will be tested with simulated click events with Robotium.
Views	Custom views allow KickShot for Android to display board items such as dice, ball chips, and goal chips. Custom Views will be tested with Android JUnit

Table 1. Items to be Tested

Environmental Requirements

The KickShot for Android Test Suite should be ran on Hardware Devices. There are multiple ways to run the Test Suite, all depending on how the tester wants to interact the tests. Developers can run the tests while developing new features for the application by running the tests within Eclipse with "Run as Android Junit Test", while testers can simply use Spoon (described below) to run the test suite against multiple Android devices.

###Hardware

To test KickShot for Android on an actual device, the tester must have an Android phone with Jelly Bean and a cable to connect the device to a testing machine.

###Software

To perform tests, the tester must have the most recent version of KickShot for Android's Android Application Package file (APK).

###Tools

A number of Android and third party tools are used while testing the KickShot for Android application:

Tool	Purpose
Android JUnit	An extension of JUnit which allows developers to make assertions about values returned from Java libraries/code.
Robotium	A testing framework for Android that allows the scripting of User Interaction.
Spoon	An Android test runner that will run a test suite against multiple Android devices (both Hardware and Virtual) and report the test results in a graphical format.

Table 2. Testing Tools

Features To Be Tested

Testing Feature	Type of Test
Click Junior Button	Integration Test
Click Menu Button	Integration Test
Role Dice	Integration Test
Board/ballTowardsAway	Unit Test
Board/ballTowardsHome	Unit Test
Board/ballMove	Unit Test
Board/ballPosession	Unit Test
Board/dicePositionAway	Unit Test
Board/dicePositionHome	Unit Test
Board/diceChangeFace	Unit Test

Features Not To Be Tested

• User Manual
• Software Requirements Specification
• Software Design Documents
• Third Party Libraries

Approach

Before a new piece of functionality is written, the developer should write the appropriate test(s) for the new function. This will allow the tests to be considered correct; then the developer can make changes to the appropriate class(es).

###Unit Testing

Unit Testing will be accomplished using Google's Android JUnit library.

###Integration Testing

Integration Testing will be accomplished using Robotium to test the user interaction with the Activities.

####Pressing the Application Icon When a user clicks the application icon (the home button) they should be directed to the Main Activity. If the user is on the Main Activity, the Application Icon should do nothing.

####Menu Buttons Clicking on the Menu icon in the Action Bar should show links to the LevelOneRules Activity, which when clicked on should take the user to the LevelOneRules Activity.

###Regression Testing All changes made to the application code will be followed by compilation and test runs to ensure that features are still functioning properly.

###Acceptance Testing Throughout the semester, prototypes and design changes will be presented to the customer to test the changes being made to the application.

Pass / Fail Criteria

###Pass Criteria

Acceptance testing is carried out by the customer upon application presentation. The application must pass the acceptance criteria of:

• Vitually Simplistic
• Visually Appealing
• Functionality meets the customer's specification
  • Ease of use
  • Implements the rules of KickShot Junior

###Fail Criteria

Any behavior that does not fit the above criteria, or complicates usability in the application will deem the task a failure.

Testing Process

###Test Deliverables For acceptance testing, the final working product will be the accepted deliverable. This includes all the documentation associated with KickShot for Android application.

###Testing Schedule Tests will be ran with Spoon with every change to the code.