Search4Yummy

Acceptance Test Plan

Version 1.0

Doc. No.:

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

Revision History
Date

Version

Description

Author

2011-11-06

0.1

Initial Draft

Yehui Wang

2011-11-09

0.5

Review, update

Muhammad Sulyman

2011-12-15

0.9

Modification after requirement change:

Yehui Wang

2011-12-15

1.0

1.

Modified section 5.

2.

Modified test case 10.1.1.4 : Add

Restaurant Grading (1-5) and
Comment Grading (1-5)

3.

Modified test case

Modified
Like
Recommend a dish
Grading (1-5) and
comment

Review

10.1.1.7 :
a
dish,
--> Dish
Add dish
Muhammad Sulyman

Page 3

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

Table of Contents
1.

Introduction
1.1
Purpose of this document
1.2
Intended Audience
1.3
Scope
1.4
Definitions and acronyms
1.4.1 Definitions
1.4.2 Acronyms and abbreviations
1.5
References

2.

Test-plan introduction

3.

Test items
3.1
Presentation layer
3.2
Logic layer
3.3
Data layer
3.4
End-to-end Scenario
3.5
Non-functional Scenario

4.

Features to be tested

5.

Features not to be tested

6.

Approach
6.1
Approach to configuration and installation

7.

Item pass/fail criteria

7.1
Installation and Configuration
7.2
Documentation problems

8.

Suspension criteria and resumption requirements

9.

Environmental needs
9.1
Hardware
9.2
Software
9.3
Other

10.
10.1

10.2
10.3
10.4

Test procedure
Test case specifications
10.1.1 Mobile application-MA
10.1.2 Web Application for Restaurant Stuff WAFRS
10.1.3 Web Application for Administrator WAFA
Test plan
Developers
User representative

11.

Risks and contingencies

12.

Approvals

Page 4

Project Name: Search4Yummy

Acceptance Test Plan

1.

Version:
1.0
Date: 2011-12-16

Introduction

1.1
Purpose of this document
This document is to describe acceptance test plan for Search4Yummy project. This project will be tested with all
the test cases specified in this document to verify that the project meet all the customer requirements. Any
aspect concerned with testing is specified in this document.
1.2
Intended Audience
This document is intended for:
Supervisor : Aneta Vulgarakis
Team Members
DSD teachers
All other stakeholders who are interested in this project
1.3

Scope

This document includes the plan, items, scope, approach, environment and procedure of Search4Yummy
acceptance test. Also the pass/fail criteria of the test items are defined. After that, the responsibilities of
developers and user representatives are identified. At last, risks and contingencies are specified to ensure the test
reliability. Other information not related to the test activities is not included in this document.
1.4

Definitions and acronyms

1.4.1

Definitions

Keyword
Search4Yummy

1.4.2

Definitions
Project name

Acronyms and abbreviations

Acronym or
abbreviation
Search4Yummy
DSD
SVN
WP7

Definitions
Search for Yummy
Distributed Software Development
Subversion, an open source version control system
Windows Phone 7

1.5
References
Search4Yummy Requirements and Design Document
http://www.fer.unizg.hr/rasip/dsd/projects/search4yummy/documents
Page 5

Project Name: Search4Yummy

Acceptance Test Plan

2.

Version:
1.0
Date: 2011-12-16

Test-plan introduction

This Search4Yummy product will be verified and validated to meet all the requirements outlined in the
requirement definition document. Unit test cases will be designed separately for the presentation layer (mobile
application and web application), logic layer and data layer. Integration test cases will be designed to test the
end-to-end scenarios. And some performance tests will also be included to verify some of the non-functional
requirements.

3.

Test items

Based on the requirements definition and design description, products three layers module scenarios, end-toend scenarios and non-functional scenarios will be tested.
3.1

Presentation layer

Presentation layer contains mobile application and web application. Developer will design unit test for each
feature included in the presentation layer which mainly include actions of customers, restaurant stuff and
administrator.
3.2

Logic layer

In logic layer, it contains several components like comment services, user services, authorization services,
restaurant services, vote services and dish service which are the bridges used to be the connections between
presentation layer and data layer. Developer will design unit test for each component included in this layer.
3.3

Data layer

The data layer contains all the components that directly manage data in the database. Developer will test each
component using unit test like an interface test.
3.4

End-to-end Scenario

In the end-to-end scenario, all the features following the requirement definition document will be tested that are
categorized as different initiators including register/unregister users, restaurant stuff and administrator.
3.5

Non-functional Scenario

For usability, the mobile and web UI design should be friendly.

For accessibility, Android platform is used for mobile application. Different browsers are supported to access to
web application like IE, Google Chrome, Mozilla Firefox, etc.
For performance, response speed of application should be at an acceptable level.
For portability, if our mobile application is supported by WP7 except for Android or if our database server is
supported by other technologies like SQL server 2008 except for MySQL, we should consider to test related
portability.

4.

Features to be tested

Features that will be tested are as following:

Identity
USM-1
USM-2
USM-3
USM-4

Sta
tus

Prio
rity

Description

Source

I
I
I
I

M
M
M
M

Mobile application for registered user

User can search for a restaurants according to user preference
User can see restaurant details
User can see restaurant menu
User can search for a specific dish in all restaurants or specific
restaurant

SYS
SYS
SYS
SYS
Page 6

Project Name: Search4Yummy

Acceptance Test Plan

USM-5
USM-6
USM-7
USM-8
USM-9
USM-10
USM-11
USM-12
USM-13
USM-14

I
I
I
I
I
I
I
I
I
I

M
M
M
M
M
M
M
M
M
M

GUM-1
GUM-2
GUM-3
GUM-4
GUM-5
GUM-6

I
I
I
I
I
I

M
M
M
M
M
M

GUM-7

RS-1

RS-2
RS-3
RS-4
RS-5
RS-6
RS-7

I
I
I
I
I
I

M
M
M
M

ADM-1
ADM-2
ADM-3
ADM-4
ADM-5
ADM-6
ADM-7

I
I
I
I
I
I
I

S
S
S
M
M
M
M

ADM-8
ADM-9
ADM-10

I
I
I

M
M
M

NFR-3

NFR-4

NFR-1

M
M

Version:
1.0
Date: 2011-12-16

User can see dish details

User can grade a dish
User can comment a dish
User can save a dish
User can comment about restaurant
User can add photo from restaurant
User can check-in in restaurant
User can view news
User can register to restaurant news
User can register for specific restaurant type news
Mobile application for unregistered user
Guest can register on Search4Yummy system
Guest can login to the Search4Yummy
Guest can search for a restaurants according to user preference
Guest can see restaurant details
Guest can see menu
Guest can search for a specific dish in all restaurants or specific
restaurant
Guest can see dish details
Web application for restaurant staff member
Restaurant staff member updates seat availability for his
restaurant
Restaurant staff member views its restaurants menu
Restaurant staff member adds new dish in restaurant menu
Restaurant staff member deletes existing selected dish
Restaurant staff member updates information about selected dish
Restaurant staff member adds news about its restaurant
Staff member updates information about his restaurant
System Administration
Administrator browses users in system
Administrator adds new user in system
Administrator deletes selected existing user
Administrator browses restaurants in system
Administrator adds new restaurant in the system
Administrator deletes selected existing restaurant
Administrator updates information about selected existing
restaurant
Administrator browses staff members of selected restaurant
Administrator adds new staff member for selected restaurant
Administrator deletes selected staff member
Nonfunctional Requirements
Mobile application must be developed for Android mobile
platform.
Web application must be compatible with next browsers:
Internet Explorer, Google Chrome, Mozilla Firefox, Opera and
Safari
Mobile and web application must be user friendly simple for
using

SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
SYS
DEV

DEV

Requirement priority:
M - Must have this requirement to meet the business needs.
S - Should have this requirement if possible, but project success does not rely on it.
C - Could have this requirement if it does not affect anything else in the project.
Page 7

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

W - Would like to have this requirement later, but it won't be delivered this time.

5.

Features not to be tested

NFR-2: Mobile application could be developed for WP7 mobile platform.
NFR-5: Independence on database type and easy portability to other database systems.
NFR-6: Good database performance, which will require as good as possible database design.
NFR-7: Acceptable response speed of the application.
NFR-8: The system should be capable to manage big amount of users.
NFR-9: Reliability.
NFR-10: Highly availability available at any time of day.

6.

Approach

Acceptance test will be executed based on this acceptance test plan. And after all test cases are executed, a test
report will be summarized to show the quality of this product. Following test approaches will be used in test
execution:
Unit test: Developers are responsible for unit test of modules of three layers.
Integration test: After the unit test is passed, testers will execute the integration test cases including
lab test and outdoor test. After all the modules are integrated, end-to-end scenarios will be tested to
ensure the communication functionality.
Regression test: After developers fix the bug in one feature, regression test will be executed by
testers to ensure that the other functions are not affected.
6.1

Approach to configuration and installation

7.

Mobile application: software on the Android platform following the installation manual is
required. And manual should be supplied by developer.
Web application: Software and hardware requirement could refer to section 9. Other test
environment could be setup by the requirements of developers.

Item pass/fail criteria

Test cases are specified in section10.

- Follow precondition specified in test procedure.
- Follow input definitions specified in test procedure
- If output result doesnt follow output definition specified in test procedure, it fails.
- If output result follows output definition specified in test procedure, it passes.
7.1
Installation and Configuration
Setup hardware and software test environment follow section 9 for mobile application and web application, then
it wont affect test.
7.2
Documentation problems
Requirement definition should be updated in time in case requirement changed.
Test plan should follow the real requirements from the customer.
User manual should be finished before the product released.

8.

Suspension criteria and resumption requirements

Tester should keep in touch with developers all the time when test is going on. If any bugs found can be fixed by
developers quickly and no need to start the testing process from the beginning. However, when major bugs such
as the communication between mobile and web application occur, it will block the following test cases and the
testing has to be paused. The test will restart from the very beginning until the major error is solved.

Page 8

Project Name: Search4Yummy

Acceptance Test Plan

9.

Environmental needs

9.1

Hardware
Mobile with Android platform
Server to setup web application.

9.2

Version:
1.0
Date: 2011-12-16

Software

Operating system
- Windows
Mobile Platform
- Android
Browsers
- Microsoft Internet Explorer
- Google Chrome
- Mozilla Firefox
- Opera
Technology
- JAVA SDK
- MySQL Database
- Eclipse IDE
Framework
- Spring
- Struts Framework
- JPA/Hibernate Framework

9.3

Other

10.

Test procedure

10.1

Test case specifications

10.1.1 Mobile application-MA

10.1.1.1
User registration-MA-01
Description:
Guest registration on Search4Yummy system
Test type:
Positive&Negative
Preconditions:
Register information must be unique
Input definition:
1. Open register page;
2. Input register information(username, password, e-mail, first and second name, city, country);
3. Submit.
Output definition:
1. System informs user about successfully created user account;
2. User information has been stored into database.
Remarks:
Example:

Page 9

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

10.1.1.2
User Login-MA-02
Description:
Login to the Search4Yummy
Test type:
Positive&Negative
Preconditions:
User already exists in system
Input definition:
1. User input username and password into login box;
2. Login.
Output definition:
1. User login the system successfully.
Remarks:
Example:
10.1.1.3
Restaurant Search-MA-03
Description:
Search for the restaurants according to user preference.
Test type:
Positive&Negative
Preconditions:
1. Mobile could search signal from Operator
2. Location:
a. GPS is opened to determine Users location
b. If GPS couldnt determine Users location or User wants to search restaurants at certain
location (not on his location), User enters his location.
Input definition:
1. User input search criteria for search restaurant,
a. Type of restaurant and/or food, number of seats he needs;
b. Random restaurant based on the maximum distance that User enters from his/selected
location.
Output definition:
1. System shows list of restaurants that have met chosen criteria.
2. User can sort restaurants by its popularity, seat availability and distance from his/selected location.
Remarks:
Example:
10.1.1.4
Restaurant View and Comment -MA-04
Description:
Restaurant details view.
Test type:
Positive
Preconditions:
1. Restaurant to be viewed has been selected by search
Page 10

Project Name: Search4Yummy

Acceptance Test Plan

2.
3.

Version:
1.0
Date: 2011-12-16

System shows selected restaurant details (name, popularity, location, comments, photos, news)
If User wants to comment restaurant, he must login first.

Input definition:
1. User can view restaurant menu;
2. User can write a comment about restaurant
3. User can add a photo of restaurant
4. User can register for news from selected restaurant
5. User can clicks on five starts to grade the selected restaurant.
6. User can clicks on five starts to grade the comments of other users.
Output definition:
1. For input 2, System saves comment and informs user about successful comment adding.
2. For input 3, System saves photo and informs user about successful photo adding.
3. For input 4, System confirms that user is registered for news.
4. For input 5, System saves grade and displays the result after user grading.
5. For input 5, System saves grade and displays the result after user grading.
Remarks:
Example:
10.1.1.5
Menu View -MA-05
Description:
Menu details view.
Test type:
Positive
Preconditions:
1. Restaurant to be viewed has been selected by search
2. System shows selected restaurant details (name, popularity, location, comments, photos, news)
Input definition:
1. User click menu and sorts dishes by type, name or price;
Output definition:
1. System shows list of dishes which are on menu sorted by type, name or price.
Remarks:
Example:
10.1.1.6
Dish search -MA-06
Description:
Search for a specific dish in all restaurants or specific restaurant.
Test type:
Positive
Preconditions:
Input definition:
1. User chooses specific restaurant, type of restaurant or all restaurants option;
2. User enters dish name.
3. User can choose dish type and/or price
Output definition:
1. System shows list of dishes that met chosen criteria
Page 11

Project Name: Search4Yummy

Acceptance Test Plan

2.

Version:
1.0
Date: 2011-12-16

User can select a dish from the list

Remarks:
Example:
10.1.1.7
Dish View and Comment-MA-07
Description:
Dish details view
Test type:
Positive
Preconditions:
If User wants to comment some dish, he must login first.
Input definition:
1. User can see dish details (name, popularity - likes commendations, grade, restaurant, type and price).
2. User clicks on five starts to grade the selected dish.
3. User clicks on want it option for the selected dish.
4. User could comment for the selected dish.
Output definition:
1. For input 2, System saves grade and displays the result after user grading.
2. For input 3, System saves dish on wish list and informs user about successful saving.
3. For input 4, System saves comments and informs user about successful comment.
Remarks:
Example:
10.1.1.8
Check In-MA-08
Description:
User checks-in in specific restaurant in which he are at the moment so other users can see who have been in
restaurant.
Test type:
Positive
Preconditions:
1. User needs to login.
2. At least two users online.
Input definition:
1. Determine Users location:
a. Using GPS;
b. If GPS couldnt determine the location exactly, system shows list of restaurants near selected
location and User chooses a restaurant.
c. If GPS doesnt work, user chooses a restaurant as his location;
2. System offers user to check-in in restaurant.
3. User checks-in in restaurant.
Output definition:
1. System informs user about successful check-in.
2. Other online Users could see who has been in this restaurant.
Remarks:
Example:

Page 12

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

10.1.1.9
News registration for restaurant type -MA-09
Description:
Register user to follow news from specific type of restaurants.
Test type:
Positive
Preconditions:
1. User needs to login.
Input definition:
1. User chooses news based on type of restaurants.
Output definition:
1. System confirms that User is registered for news
Remarks:
Example:
10.1.1.10
News View-MA-10
Description:
User has option to read news on which he is registered to follow.
Test type:
Positive
Preconditions:
1. User needs to login.
2. System shows user news on which he is registered.
Input definition:
1. User browses news.
2. User can sort news by time, restaurant or type of restaurants.
Output definition:
1. For input 1, OK.
2. For input 2, OK.
Remarks:
Example:
10.1.2 Web Application for Restaurant Stuff WAFRS
10.1.2.1
Update seat availability-WAFRS -01
Description:
Staff member updates seat availability for his restaurant.
Test type:
Positive
Preconditions:
1. Restaurant Stuff is logged in.
Input definition:
1. Staff member enters seat availability (number of available seats).
2. Staff member can change restaurant capacity.
Output definition:
Page 13

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

3. For input 1, OK.

4. For input 2, OK.
Remarks:
Example:
10.1.2.2
Update Menu-WAFRS -02
Description:
Staff member updates its restaurants menu.
Test type:
Positive
Preconditions:
1. Restaurant Stuff needs to login.
2. System shows list of dishes in restaurant menu
Input definition:
1. Staff member can choose dish and remove it
2. Staff member can choose dish and update information (name and type of new dish) about it.
3. Staff member can add new dish (name and type of new dish).
Output definition:
1. For input 1:
a. System confirms that dish was successfully deleted
b. System informs users, who are registered to news of restaurant, that dish is deleted from
restaurant menu.
2. For input 2:
a. System confirms that dish was successfully updated
b. System informs users, who are registered to news of restaurant, about changes in restaurant
menu
3. For input 3:
a. System confirms that dish is successfully added
b. System informs users, who are registered to news of restaurant, about new dish in restaurant
menu.
Remarks:
Example:
10.1.2.3
Add news -WAFRS -03
Description:
Staff member adds news about its restaurant.
Test type:
Positive
Preconditions:
1. Restaurant Stuff needs to login.
Input definition:
1. Staff member enters new news about its restaurant
Output definition:
1. System confirms that news was successfully added.
2. System informs users, who are registered to news of restaurant, that news has been added.
Remarks:
Example:
Page 14

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

10.1.2.4
Update restaurant info -WAFRS -04
Description:
Staff member updates information about his restaurant.
Test type:
Positive
Preconditions:
1. Restaurant Stuff needs to login.
Input definition:
1. Staff member update news about its restaurant
a. change name of the selected restaurant
b. change type of the selected restaurant
c. change location of the selected restaurant
Output definition:
1. System confirms that restaurant news was successfully updated.
2. System informs users, who are registered to news of restaurant, about changes of restaurant
information.
Remarks:
Example:
10.1.3 Web Application for Administrator WAFA
10.1.3.1
Update Users Info-WAFA -01
Description:
Administrator updates users information.
Test type:
Positive
Preconditions:
1. Administrator needs to login.
2. System shows a list of users in system
Input definition:
1. Administrator browses the list
2. Administrator can update user list:
a. add new user
b. Select user form the list and delete him.
Output definition:
1. For input 2a:
a. Database creates new user
b. System informs administrator about successfully created user account.
2. For input 2b:
a. System confirms that user was successfully deleted
b. System informs user by e-mail that his account is deleted and no longer available
Remarks:
Example:
10.1.3.2
Update Restaurant Info-WAFA -02
Description:
Administrator updates Restaurants information.
Page 15

Project Name: Search4Yummy

Acceptance Test Plan

Version:
1.0
Date: 2011-12-16

Test type:
Positive
Preconditions:
1. Administrator needs to login.
2. System shows a list of restaurant in system
Input definition:
1. Administrator browses the restaurants list
2. Administrator can add new restaurant.
a. Administrator enters name of the restaurant
b. Administrator enters type of the restaurant
c. Administrator enters location of the restaurant
d. Administrator enters initial capacity of the restaurant
3. Administrator can select restaurant form the list and delete it.
4. Administrator can select restaurant form the list and update it
a. Administrator can change name of the selected restaurant
b. Administrator can change type of the selected restaurant
c. Administrator can change location of the selected restaurant.
Output definition:
1. For input 2: System confirms that restaurant was successfully added
2. For input 3:
a. System confirms that restaurant was successfully deleted
b. System informs users, who are registered to news of deleted restaurant, that restaurant is no
longer available.
3. For input 4:
a. System confirms that restaurant was successfully updated
b. System informs users, who are registered to news of restaurant, about changes of restaurant
information.
Remarks:
Example:
10.1.3.3
Update Restaurant stuff info Info-WAFA -03
Description:
Administrator updates Restaurant stuffs information.
Test type:
Positive
Preconditions:
1. Administrator needs to login.
2. System shows a list of restaurant stuff for selected restaurant in system
Input definition:
1. Administrator browses the restaurants stuff list
2. Administrator can add new stuff member.
a. Administrator fills a form for new staff member registration.
b. Administrator creates new staff member for select restaurant.
3. Administrator can select a restaurant stuff form the list and delete it.
Output definition:
1. For input 2:
a. System creates new staff member for select restaurant
Page 16

Project Name: Search4Yummy

Acceptance Test Plan

2.

Version:
1.0
Date: 2011-12-16

b. System informs administrator about successfully created staff member account.

For input 3:
a. System confirms that staff member was successfully deleted.
b. System informs staff member by e-mail that his account is deleted and no longer available.

Remarks:
Example:
10.2
Test plan
We will start testing the Web Application and the Mobile Application together because the implementation of
both of these is being done in parallel so they will be ready simultaneously. In the Web application staff
members portion and the administrator portion will be tested at the end because they will be developed at the
end.
10.3
-

Developers
Unit test before merging code to the main track.
Fix bugs from unit test, system test and regression test.

10.4
-

User representative
Keep an eye on the progress of test.
Adding or modification of requirements in time.

11.

Risks and contingencies

-

12.

Couldnt make sure using all the browsers to test web application.
Couldnt make sure using several smart phones to test the whole system.

Approvals

Name

Title

Date
yyyy-mm-dd

Signature

Page 17