Fast Past Parking

Test Plan

Cop 4331, Fall, 2014

Modification history:

Team Name: Group 13 - Fast Pass Parking

Team Members:

• Ivan Lugo: ivan.lugo@knights.ucf.edu
• Jason Braswell: jason.braswell@knights.ucf.edu
• Kyle Mera: kmera1@knights.ucf.edu
• Pedro Poveda: pedropovedaq@knights.ucf.edu
• Alex Gordon: alexgordon@knights.ucf.edu
• Darin Doria: doria@knights.ucf.edu

Contents of this Document

1. Introduction
2. Description of Test Environment
3. Overall Stopping Criteria
4. Description of Individual Test Cases

SECTION 1: Introduction

The Software Test Activity for this project will cover all of the applicable testing scenarios and cases for mobile application development. Within this document the testing environment will be noted and described. Additionally, the stopping criteria for the project’s testing procedures will be stated. Lastly, the individual test cases for each of the system’s features will be defined, along with acceptance criteria.

Reference Documents

• Concept of Operations
• Project Plan
• SRS

SECTION 2: Description of Test Environment

The hardware for the development environment includes a Linux workstation for the web server. Additionally, hardware for testing the application includes Apple devices such as the iPad and iPhone. iPads and iPhones are the target platforms for the application as well. Unit testing will be done on Mac OSX environments. Acceptance testing will be done on actual Apple devices.

SECTION 3: Stopping Criteria

• The project will employ unit, integration, and regression testing methodologies. A feature will be developed then it will be tested as a single unit. Afterwards, the feature will be integrated into the rest of the application. At that point, another round of testing will occur - integration testing. If the feature impacts any previous development, regression analysis will be performed.
• Each feature will be tested by the initial developer. Once the feature has been completed by the developer, he/she will send the feature to at least one other developer to test. The standard is a minimum of one user, who is not the creator, to approve a feature before it is considered fully completed.
• A fully completed feature will not have any programming bugs and must have any requirements for styling completed as well when the feature is considered ‘final’. Before this, each feature must be branched on the platform GIT repository and worked on separately as a unit. Minor cosmetic issues may be ignored on a case-by-case basis. Known errors will generally not be allowed, but are also on a case-by-case basis as decided by the entire group.

SECTION 4: Description of Individual Test Cases

Objective: User login/sign-up page (All users)

Description : Two types of users: Company Attendant, ParkingUser; they should be able to login using a username and password from the login page on the mobile application. In the case of a Company Attendant, the first iteration of the application will have credentials manually added by the developers to allow all attendants within a company to access the same dataset without providing uniquing. This is a purposeful decision to decrease development time, and allow for feature progression. ParkingUser users will be able to sign up for the app from the intial ‘Sign In / Sign Up’ view.

Conditions : Conditions described in aforementioned general testing conditions. This page requires no previous navigation by the user.

Expected Results : If logged-in successfully with username/password combination, user should be directed to lot index page of application. If wrong username/password, invalid credentials message should appear. ParkingUsers will fill out data needed and then be redirected to appropriate index pages when choosing to sign up.

Objective: User dashboards (All)

Description : All index pages for users should have a dashboard which gives a summary and navigation ability to each of the user’s features.

Conditions : Conditions described in aforementioned general testing conditions. This page should be accessed shown after login.

Expected Results : User will see dashboard and be able to get to any of the predefined features listed.

Objective: Parking lot selection (ParkingUser)

Description : Parking users should be able to select a parking lot. By default, the application should see if the user is within the GPS coordinates of a predefined parking lot location. Parking lots should be shown to user in ascending order based on distance. This algorithm for list management is subject to change.

Conditions : Conditions described in aforementioned general testing conditions. This page should be accessed from index page of this user.

Expected Results : User will see list of parking locations nearest him/herself, along with an accompanying picture. Upon selection user will move to ‘pay for parking’ screen.

Objective: Pay for parking (ParkingUser)

Description : Allows for user to select a and pay for a time block. Shows the rate and total amount.

Conditions : Conditions described in aforementioned general testing conditions. This screen will be accessed from the �parking lot selection� screen.

Expected Results : User will use a time picker to select a time block. The rate of the lot multiplied by the time will show the amount to pay. Once user selects and confirms, payment will process.

Objective: Parking expiration notifications (ParkingUser)

Description : Notifies parking users that their time is about to expire and allows them to add more time.

Conditions : Conditions described in aforementioned general testing conditions. This screen will be accessed from the ‘pay for parking’ screen.

Expected Results : Server will automate sending messages to users 15 minutes before expiration. Timing is subject to change and is optional per user specifications. Server vs. local notification subject to change. A notification should appear on the user’s screen (with respect to notification settings on device). Upon selecting the notification, the user will be redirected to the �pay for parking screen.�

Objective: Manage profile (All users)

Description : Gives users the ability to update general account information, including online payment methods.

Conditions : Conditions described in aforementioned general testing conditions. This screen can be accessed from all pages once logged in.

Expected Results : User will be able to select profile icon from any page once logged in. Then the user will be redirected to screen where he/she can edit basic account information and online payment. Companies will be able to update parking lot(s) and check select statistics.

Objective: View cars in parking lot (Attendant)

Description : Shows user who is parked in parking lots assigned to said user.

Conditions : Conditions described in aforementioned general testing conditions. This screen can be accessed from user’s index page.

Expected Results : Screen should show a license plate listing of the currently parked cars. Upon selecting one of these, attendant will see data on how much time is left and allow for ticketing of a user (assigning fee to account).

Objective: Create / Remove parking lots on confirmation (Company)

Description : Gives ability to create geo-locations that are defined parking lots.

Conditions : Conditions described in aforementioned general testing conditions. This screen should be accessed from user’s index page.

Expected Results : User can map out points on a map (polygons) that creates a parking lot. User can create multiple parking lots. User can set hourly rate for each parking lot. The company log in will also allow for removal of a lot.

This page last modified by Jason Braswell (jason.braswell@knights.ucf.edu) on September 17, 2014