SnapValet ARBTeam 03

1

Test Plan & CasesMolly Karcher

2

Testing Strategy Overview

• Unit testing• JUnit & Eclipse

• Value-based prioritization

• Automated Functional Testing• Using Android ActivityMonitor

• Functional tests map to TC-01 through TC-07 from TCP

• Requirements-Test traceability

• Test suite run on-commit

• Formal Quality Testing (Acceptance Testing)• Functional tests performed manually on clients pointing to a

deployed production box

3

Functional Test Cases

• TC-01-01 Create a Driver User Profile

• TC-01-02 Create a Valet User Profile

• TC-01-03 Edit a Driver User Profile

• TC-02-01 Check-in at Location as Valet

• TC-02-02 Create a new Valet Shift

• TC-02-03 Receive Retrieval Requests on Valet Queue

• TC-02-04 Acknowledge & Edit Customer Retrieval Requests on

Valet Queue

• TC-02-05 Send Re-parking Notification from Valet Queue

• TC-02-06 Close out Valet Shift

• TC-03-01 Driver Check-in at Location

4

Functional Test Cases

• TC-04-01 Car Retrieval Request

• TC-05-01 Process Mobile Payment through App

• TC-05-02 Opt out of Mobile Payment

• TC-05-03 Post-Pickup Confirmation Email & Receipt

• TC-06-01 Create Valet Company Administrative Account

• TC-06-02 Add Employees through Administrative Account

• TC-06-03 Add Managed Locations through Administrative Account

• TC-06-04 Remove Employees through Administrative Account

• TC-06-05 Remove Managed Locations through Administrative

Account

• TC-07-01 Scale to 25,000 Users.

5

Example: TC-04-01 Car Retrieval Request

6

SnapValet ARB Team Evaluation Molly Karcher

7

Strengths and Weaknesses: Operational ViewStrengths• All members are friendly,

collaborative, and punctual in regards to deadlines

• Strong sense of communal responsibility for deliverables

• Client is very available, agreeable, and responsive

• Quick and decisive in task delegation; good sense of communal responsibility

• Use of online collaboration tools (Google groups, Bugzilla, Winbook, Facebook messages, etc.

• Better cross-role collaboration since first ARB

Weaknesses• Deliverables generated very

close to deadlines, leaves minimal time for verification

• Lack of availability of remote team member during normal workday hours

• Becoming less conscientious about sending meeting minutes and updating Bugzilla tasks as final exams for other classes approach

• Will lose one teammate in 577b

8

Strengths and Weaknesses: Technical View

Strengths

• All computer science Masters students - quickly & effectively learn new technologies

• Strong familiarity with MySQL

• Strong familiarity with Java (easy transition to Android)

• Some of the team took Web Tech this semester

• COTS tools nailed down and prototyped

Weaknesses

• Lack of mobile development experience

• Lack of familiarity with Braintree API

• Scope creep• Lack of experience

building scalable systems from scratch

9

Overall Project Evaluation

• Detailed/feasible, though very ambitious schedule for 577b– Development will need to be very closely tracked to

ensure we maintain schedule.

• All high risks have been identified as requirements stabilized, and all have mitigation plans, but have not actually be mitigated yet– At present, not all Win Conditions have been prototyped

• Technical architecture was developed very thoroughly and with collaboration of entire team, so it is very well understood – Should ease initial phases of development & learning

curve for all developers

10

Operations Concept Description

Abhinandan Patni

11

Outline

• System Purpose

• Shared Vision

• Proposed System

• Benefits Chain Diagram

• System Boundary

• Desired Capabilities and Goals

12

System Purpose• To enable cashless transactions for valet parking payment.

• To increase the speed of the valet pick-up service.

• To improve the valet experience of customers.

• To facilitate better transaction and account management

for valet companies.

13

Shared Vision

14

Proposed System – Entity Relationship Diagram

15

Proposed System – Business Workflow Diagram

16

Benefits Chain Diagram

17

System Boundaries

18

Desired Capabilities

• Mobile Transaction (OC1)

• Notifications (OC2)

• Admin Interfacing (OC3)

• Geolocation Checkin (OC4)

• Profile Managment (OC5)

• Advertisements and Suggestions (OC7)

19

LEVELS OF SERVICE• Response Time – 1-3 seconds between screens.

• Availability – Maximum downtime of 10 mins during heavy

usage hours (Weekdays – 6-9pm, Weekends – 6-10pm)

• Security – In addition to intrusion and cyber attacks, we

have developed a few functionality test cases to account

for other security flaws.

• Maintainability – Will be handled by a SnapValet employee

once the project is complete next May. Modularity in code

to keep things simple.

• Scalability – Adapt the system for multiple servers and to

handle around 100 requests at the same time. 20

Organizational and Operational Transformations

• Need for central tablet per valet parking area.

• Employee IDs a must.

• Update the list of restaurants serviced.

Customers have to enter ticket numbers

Valets are notified of requests on the tablet.

Customers are notified on their smartphones by valet.

Payment can be done via mobile transaction.

21

Prototype IIBrian Vanover

22

Outline

• SnapValet Refresher

• Java Client-Server Simulation

• Request & Pay

• Retrieve & Return (started)

• Android/Java Braintree Proof of Concept

23

Vehicle Request

Following check-in, customers can request their vehicle by entering the number on the ticket that was given to them by the valet.

This will generate a request that will be displayed in the valet queue following a prompt for payment

Request Activity-requestTicketNumber-validateTicketNumber-putExtra-startPaymentActivity

24

Payment

Customers will have the option of paying cash or mobile.

Payment will be verified before release of the vehicle

Payment Activity-getLocationFee

- Realized efficiency

-requestTip- validateTip (double)

-putExtraPayment-submitRequest-startThanksActivity

25

Request Queue

Interface for Valet interaction with request queue

QueueActivity-CRUD Operations-displayQueue-parseResponse

- Efficiency Realization

QueueUpdateRetriever-New Thread-run(): request updates from server periodically

26

SnapValetServer

Main-Socket-Case-based Parsing-Simulated DBs

QueueUpdater-addValetRequest-updateQueue

27

Braintree API• Android/Java• Simple demonstration of credit

card transaction

28

RequirementsRidhima Manjrekar

29

Outline

• High Priority Requirements

• Major changes

• Not agreed/Potentially agreed

• Future Requirements

30

High Priority Requirements• Geo-location check-in : both customer and the valet

• Secure payment transaction : credit card information

encrypted

• System to be available during heavy usage hours

• Valet companies to be registered to manage their

employees and transactions.

• Valet to receive real time requests from the customers

• Valet to be able to notify the customer

31

Major Changes• Tips not pooled now

• Braintree app to be used for payment transaction

• Valet company will not get detailed report of transaction

• Valet company have to be registered with Snapvalet and

should provide their employee details.

• Profile management of employees

• Customer just gets notified once

• Cost for valet service can be changed by the valet

32

Not agreed/potentially agreed• Establishments to be able to send advertisements

• System shall be capable of running an iOS client

• What kind of transaction report the valet company will get

33

Future Requirements

• To be able to work on multiple servers about 100 requests

at the same time

• Code to be modular to isolate defects

• Advertisements and Suggestions

34

ArchitectureDitong Ding

35

Outline

• System Context

• Artifacts & Information

• Behavior (Use case Diagram)

• Hardware Component Diagram

• Software Component Diagram

• Deployment Diagram

• Class Diagram

• Sequence Diagram (for two major use cases)

36

System Context

37

Artifacts & Information

38

Behavior (Use case Diagram)

39

Hardware Component Diagram

40

Software Component Diagram

41

Deployment Diagram

42

Class Diagram

43

Sequence Diagram

44

Saikarthik Desiraju

Life Cycle Plan

45

Stakeholder roles

Role Team Member

Client Mona A

Project Manager Brian Vanover

Feasibility Analyst Xiaoting Bi

IIV & V QFP

Molly Karcher

Requirements EngineerTester

Ridhima Manjrekar

System ArchitectUML Modeler

Ditong Dong

Life Cycle Planner Saikarthik Desiraju

Operational Concept Engineer Developer

New Team Member (CS577b)

System Maintainer SnapValet employee

46

Milestones

DCRDCR RDCRRDCR

CCDCCD

TRRTRR

OCROCR

47

Activities & Responsibilities

48

Activities & Responsibilities

49

Activities & Responsibilities

50

Activities & Responsibilities

51

Core CapabilitiesID Trace Capability Description Priority Iteration1 UC-1,5

TC-02-01, TC-03-01

Geo-Location check in

A customer and a valet should be able to check-in at the establishment (location) they are at.

High 1 

2 UC-6, OC-1TC-05-01

Mobile transaction

A customer should be able to pay for valet service using his credit card on the application.

High 1

3 UC-6, OC-4TC-04-01

Ticket number entry

The customer must be able to enter his valet ticket number into the application.

High 1

4 UC-6, OC-2TC-04-01

Request Vehicle A customer should be able to request for his vehicle via the app.

High 1

5 UC-4, OC-5TC-02-04

Retrieval Notification

A customer should receive a notification on his device when his vehicle is being retrieved.

High 1

6 UC-4, OC-3TC-02-04

Queue : Retrieve The valet is able to visually validate the ticket number and then notify the customer of car retrieval.

High 1

7 UC-4, OC-3TC-02-04

Queue : Report “invalid” ticket number

The valet is able to notify a customer that he/she entered a wrong ticket number

High 1

8 UC-4, OC-3TC-02-04

Queue : Close out request

A valet is able to close out a served request and remove it from the queue

High 1

9 UC-2, TC-02-02, TC-02-06

Start and close out a shift

A valet should be able to start a shift for other valets to add on to and be able to close out a shift.

High 1

10 UC-2,7, TC-01-01, TC-01-02, TC-01-03

Profile management

A customer and a valet are able to register and create a profile on the app.

High 152

Risk Management & Contingency Plans

No new team member & developer : Ridhima Manjrekar will be the Operational Concepts engineer. Prototyping continues in the winter break. Starting development early . 3rd week of January. Relevant course work Continuous assessment of apps workflow. We keep trying to break it.

GOAL : Smooth CCD (March 25th,2015)

53

Xiaoting Bi

Feasibility Evidence Description

54

Business Case Analysis

Cost & Benefits

55

Personnel Costs

56

Hardware and Software Costs

Personnel Costs (cont.)

57

Benefit Analysis

For client:

For users:

58

ROI Analysis

59

Risks

60

Risks (cont.)

61

Risks changed

Delete risks:

62

NDI/NCS Analysis

Connector

• We use Java/MySQL Connector to enable the mobile application to retrieve and update data from the database.

• We use PHP/MySQL Connector to enable the web application to retrieve and update data from the database.

Legacy System

• None.

63

NDI/NCS Analysis

64

Quality Focal PointMolly Karcher

65

Metrics Reporting: Estimate vs. Actual Hours

66

Metrics Reporting: Defect Status

67

Technical Debt

Solved

• Braintree API– Prototyped

• Google Places API– Prototyped

• Requirements Volatility– Rapid adaptation

• Scope creep– Solidification of

requirements

Unsolved

• Mobile inexperience– Solve by team completing

tutorials• Win Conditions un-

prototyped– Solve by following 577b

development schedule very closely

• Concurrency– Solve through manual and

functional testing• Scalability

– Solve through manual and functional testing

68

Traceability Matrix

OCD Requirements Use Cases Test Cases

OC-1 Mobile Transaction WC-3392, WC-3204 UC-4, UC-6

TC-04-01, TC-05-01, TC-05-02, TC-05-03

OC-2 NotificationsWC-3390, WC-3386, WC-3384, WC-3205 UC-4, UC-6

TC-02-03, TC-02-04, TC-02-05, TC-04-01

OC-3 Admin InterfacingWC-3391, WC-3387, WC-3385

UC-8, UC-9, UC-11, UC-13, UC-12

TC-02-02, TC-06-01, TC-06-02, TC-06-03, TC-06-04, TC-06-05

OC-4 Geolocation Checkin WC-3215, WC-3203 UC-1, UC-5 TC-02-01, TC-03-01

OC-5 Profile Management WC-3387, WC-3208

UC-2, UC-5, UC-7

TC-01-01, TC-01-02, TC-01-03

OC-6 Advertising WC-3210 UC-5 TC-03-01

69

Questions?

70