search4yummy - acceptance test plan

Search4YummyAcceptance Test Plan

Version 1.0

Doc. No.:

Project Name: Search4Yummy Version: 1.0Acceptance Test Plan 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:

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 10.1.1.7 : Modified “Like a dish, Recommend a dish --> Dish Grading (1-5)” and Add “dish comment”

Yehui Wang

2011-12-15 1.0 Review Muhammad Sulyman

Page 3


Table of Contents

1. Introduction 5

1.1 Purpose of this document 51.2 Intended Audience 51.3 Scope 51.4 Definitions and acronyms 5

1.4.1 Definitions 51.4.2 Acronyms and abbreviations 5

1.5 References 5

2. Test-plan introduction 6

3. Test items 6

3.1 Presentation layer 63.2 Logic layer 63.3 Data layer 63.4 End-to-end Scenario 63.5 Non-functional Scenario 6

4. Features to be tested 6

5. Features not to be tested 8

6. Approach 8

6.1 Approach to configuration and installation 8

7. Item pass/fail criteria 8

7.1 Installation and Configuration 87.2 Documentation problems 8

8. Suspension criteria and resumption requirements 8

9. Environmental needs 8

9.1 Hardware 89.2 Software 99.3 Other 9

10. Test procedure 9

10.1 Test case specifications 910.1.1 Mobile application-MA 910.1.2 Web Application for Restaurant Stuff– WAFRS 1310.1.3 Web Application for Administrator– WAFA 15

10.2 Test plan 1710.3 Developers 1710.4 User representative 17

11. Risks and contingencies 17

12. Approvals 17

Page 4


1. 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 DefinitionsSearch4Yummy Project name

1.4.2 Acronyms and abbreviations

Acronym orabbreviation

Definitions

Search4Yummy Search for YummyDSD Distributed Software DevelopmentSVN Subversion, an open source version control systemWP7 Windows Phone 7

1.5 References

Search4Yummy Requirements and Design Documenthttp://www.fer.unizg.hr/rasip/dsd/projects/search4yummy/documents

Page 5

http://www.fer.unizg.hr/rasip/dsd/projects/search4yummy/documents


2. 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, product’s three layers module scenarios, end-to-end 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 testedFeatures that will be tested are as following:

Identity Status

Priority

Description Source

Mobile application for registered userUSM-1 I M User can search for a restaurants according to user preference SYSUSM-2 I M User can see restaurant details SYSUSM-3 I M User can see restaurant menu SYSUSM-4 I M User can search for a specific dish in all restaurants or specific

restaurantSYS

Page 6


USM-5 I M User can see dish details SYSUSM-6 I M User can grade a dish SYSUSM-7 I M User can comment a dish SYSUSM-8 I M User can save a dish SYSUSM-9 I M User can comment about restaurant SYSUSM-10 I M User can add photo from restaurant SYSUSM-11 I M User can check-in in restaurant SYSUSM-12 I M User can view news SYSUSM-13 I M User can register to restaurant news SYSUSM-14 I M User can register for specific restaurant type news SYS

Mobile application for unregistered userGUM-1 I M Guest can register on Search4Yummy system SYSGUM-2 I M Guest can login to the Search4Yummy SYSGUM-3 I M Guest can search for a restaurants according to user preference SYSGUM-4 I M Guest can see restaurant details SYSGUM-5 I M Guest can see menu SYSGUM-6 I M Guest can search for a specific dish in all restaurants or specific

restaurantSYS

GUM-7 I M Guest can see dish details SYSWeb application for restaurant staff member

RS-1I

MRestaurant staff member updates seat availability for his restaurant

SYS

RS-2 I M Restaurant staff member views its restaurant’s menu SYSRS-3 I M Restaurant staff member adds new dish in restaurant menu SYSRS-4 I M Restaurant staff member deletes existing selected dish SYSRS-5 I M Restaurant staff member updates information about selected dish SYSRS-6 I M Restaurant staff member adds news about its restaurant SYSRS-7 I M Staff member updates information about his restaurant SYS

System AdministrationADM-1 I S Administrator browses users in system SYSADM-2 I S Administrator adds new user in system SYSADM-3 I S Administrator deletes selected existing user SYSADM-4 I M Administrator browses restaurants in system SYSADM-5 I M Administrator adds new restaurant in the system SYSADM-6 I M Administrator deletes selected existing restaurant SYSADM-7 I M Administrator updates information about selected existing

restaurantSYS

ADM-8 I M Administrator browses staff members of selected restaurant SYSADM-9 I M Administrator adds new staff member for selected restaurant SYS

ADM-10 I M Administrator deletes selected staff member SYSNonfunctional Requirements

NFR-1I M Mobile application must be developed for Android mobile

platform.SYS

NFR-3 I S Web application must be compatible with next browsers: Internet Explorer, Google Chrome, Mozilla Firefox, Opera and Safari

DEV

NFR-4 I S Mobile and web application must be user friendly – simple for using

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


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

5. Features not to be testedNFR-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. ApproachAcceptance 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

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.

7. Item pass/fail criteriaTest cases are specified in section10.

- Follow precondition specified in test procedure. - Follow input definitions specified in test procedure- If output result doesn’t 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 won’t 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.

9. Environmental needs

9.1 Hardware

- Mobile with Android platformPage 8


- Server to setup web application.

9.2 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:

10.1.1.2 User Login-MA-02

Description: Login to the Search4Yummy


Page 9


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.


Preconditions:1. Mobile could search signal from Operator2. Location:

a. GPS is opened to determine User’s locationb. If GPS couldn’t determine User’s 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 search2. System shows selected restaurant details (name, popularity, location, comments, photos, news)3. 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

Page 10


4. User can register for news from selected restaurant5. 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 search2. 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 criteria2. User can select a dish from the list

Remarks:Example:

10.1.1.7 Dish View and Comment-MA-07

Description:

Page 11


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 User’s location:

a. Using GPS;b. If GPS couldn’t determine the location exactly, system shows list of restaurants near selected

location and User chooses a restaurant.c. If GPS doesn’t 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:

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:Page 12


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: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 restaurant’s menu.

Page 13


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 it2. 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 deletedb. 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 updatedb. System informs users, who are registered to news of restaurant, about changes in restaurant

menu3. For input 3:

a. System confirms that dish is successfully addedb. 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:

10.1.2.4 Update restaurant info -WAFRS -04

Description: Staff member updates information about his restaurant.

Test type:Positive

Preconditions:Page 14


1. Restaurant Stuff needs to login.

Input definition:1. Staff member update news about its restaurant

a. change name of the selected restaurantb. change type of the selected restaurantc. 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 list2. 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 userb. System informs administrator about successfully created user account.

2. For input 2b:a. System confirms that user was successfully deletedb. 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 Restaurant’s information.

Test type:Positive

Preconditions:1. Administrator needs to login.2. System shows a list of restaurant in system

Page 15


Input definition:1. Administrator browses the restaurant’s list2. Administrator can add new restaurant.

a. Administrator enters name of the restaurantb. Administrator enters type of the restaurantc. Administrator enters location of the restaurantd. 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 restaurantb. Administrator can change type of the selected restaurantc. Administrator can change location of the selected restaurant.

Output definition:1. For input 2: System confirms that restaurant was successfully added2. 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 updatedb. 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 stuff’s 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 restaurant’s stuff list2. 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 b. System informs administrator about successfully created staff member account.

2. 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:

Page 16


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 member’s 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- Couldn’t make sure using all the browsers to test web application.- Couldn’t make sure using several smart phones to test the whole system.

12. Approvals

Name TitleDate

yyyy-mm-ddSignature

Page 17

search4yummy - acceptance test plan

Documents