QR Marks the Spot
Acceptance Test Plan
Version 1.0
Doc. No.:
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Revision History
Date
Version
Description
Author
2009-11-22
0.1
Initial Draft
Saud & Aftab
2009-11-23
0.2
Added Use Case Testing
Saud & Aftab
2009-12-09
0.2
Correct the Table of Contents and Format
Saud
2009-12-11
0.3
Rebeka & Marko
2010-01-11
0.4
Performing required corrections to the
document and finalizing test cases
Final version
Rebeka & Marko
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Table of Contents
1.
Introduction
5
1.1
1.2
1.3
1.4
1.5
5
5
5
5
5
Purpose of this document
Intended Audience
Scope
Acronyms
References
2.
Test-plan introduction
5
3.
Test items
6
3.1
3.2
3.3
3.4
6
6
6
6
Data layer
Service
Web Application
Mobile Device with QR Code Reader
4.
Features to be tested
6
5.
Features not to be tested
7
6.
Approach
7
6.1
7
7.
Approach to configuration and installation
Item pass/fail criteria
7
7.1
7.2
8
8
Installation and Configuration
Documentation problems
8.
Suspension criteria and resumption requirements
8
9.
Environmental needs
8
9.1
9.2
9.3
Hardware
Software
Other
8
8
9
Test procedure
9
10.
10.1
Test case specifications
10.1.1 User-QRMarks
10.1.2 Creator-QR Marks
10.1.3 Player-QR Marks
10.1.4 Visitor-QR Marks
10.2
Stress Test
11.
Responsibilities
11.1
11.2
9
9
12
14
15
15
16
Developers
User representative
16
16
12.
Risks and contingencies
16
13.
Approvals
16
QR Marks the Spot
Acceptance Test Plan
1.
Version:
1.0
Date: 2010-01-11
Introduction
1.1 Purpose of this document
This document contains the information relevant for verification and validation phases of the project. It
describes all tests required for determining whether the project results meet all the requirements.
1.2 Intended Audience
This document is intended for all project members who can give remarks, based on which we can modify and
increase test coverage. The customer can use this document to review whether all of their requirements are met
and tested. All other stakeholders can also use this document to view test procedures and actual test results.
1.3 Scope
This document describes the test case with results done after finishing the development phases. It contains
general system testing, a list of specific test for each part of the system, and a list of test case specification.
1.4 Acronyms
Acronym or
abbreviation
QR
WS
WSC
DB
MVC
Definitions
Quick Response
Web Site
Web Services
Database
Model-View-Controller
1.5 References
This document was based on the Requirements definition and Project description documents that were created at
the initial stage of the project. Use cases from Requirements definition document were used as a guideline for
specifying the test cases described in this document.
2.
Test-plan introduction
The main purpose of this phase is to test the features provided by the whole system as well as testing individual
parts of the system. To test the whole system, the functionalities were divided into 3 different categories based
on user interaction with the system:
1. Visitor
2. Player
3. Creator
QR Marks the Spot
Acceptance Test Plan
3.
Version:
1.0
Date: 2010-01-11
Test items
As described in the Design description document, the system is implemented using MVC architecture. The
system is divided into 3 layers:
1. Data
2. Service
3. Web Application
Additionally, to fully utilize all system features, a mobile application for decoding QR Codes is needed.
3.1 Data layer
Contains the data present in the database. The database was not tested individually since all tests of the upper
layers will also test database functionality.
3.2 Service
This layer was developed using Java Web services. Hibernate was used to provide the required object relational
mapping for accessing the database. The services perform all queries on the database, interact with Twitter as
needed, and provide support for all operations required by the web site. The operations were tested individually
and also implicitly while performing tests on the Web Site.
3.3 Web Application
This is the layer that the users of the system interact with. It includes PHP, Javascript and the interaction with
Google Maps and Twitter. This part is the most hard to test, because there are many features and sometimes it is
not possible to test all the instances thoroughly.
3.4 Mobile Device with QR Code Reader
Mobile device with QR code reader is required to play the games created using the system.
4.
Features to be tested
The Features that will be tested are the requirements found below:
Identity
Status
Priority
Description
Source
DB-1
DB-2
DB-3
DB-4
I
I
I
I
1
1
1
1
Database
Registered users can play created games.
Registered users can send and receive messages.
Registered users can describe and create their own games.
Registered users can comment created/played games.
Web application
PL
CR, PL
CR, PL
CR, PL
WA-1
I
1
WA-2
I
1
WA-3
I
1
User should be able to sign up
Registered users have to be able to do login and logout
User can modify and deactivate his/her account.
VIS
CR, PL
CR, PL
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
WA-4
WA-5
WA-6
WA-7
I
I
I
I
1
1
1
1
WA-8
I
1
WA-9
WA-10
I
I
1
1
WA-11
I
1
WA-12
I
1
WA-13
WA-14
WA-15
I
I
I
1
1
1
WS-1
I
1
WS-2
I
1
WS-3
I
1
5.
User can find specific games within the system.
User can find information regarding other users of the system.
User can define two game types: Race and Treasure hunt.
User can select the game to be public or private.
User can select the game to be time limited and select the desired
limitations.
User can add locations to the game he/she is creating.
User can use one geographic location for multiple game locations.
User can specify the content of QR Codes and the desired keyword for
each location.
User can specify a Twitter account that the game he/she created should
use.
QR Codes are generated according to user specifications.
User can view the next location for the game he/she is playing.
User can enter the keyword for the next location.
Service
Information about new users added to the project’s Twitter feed after
creating the user account.
Information about new games added to the project’s Twitter feed after
creating the game.
Player actions while playing the game (e.g., joining the game, finding
the next location etc.) added to the game’s Twitter feed if one is
specified.
CR, PL
CR, PL
CR
CR
CR
CR
CR
CR
CR
PL
PL
Features not to be tested
The database will not be tested as an individual component. It is assumed that the service layer will perform the
appropriate integrity checks and that all data retrieved from the database is unaltered.
6.
Approach
Different testing approaches will be used for testing the project. The main are:





Normal test – consists in testing the features trying to cover all the requirements
Component test – consists in testing each component alone, before integrates it in the system
Random Test – consists in selecting some random part to add more test to Normal test and to go deeper
in some parts
Faulty testing – consists in trying to feed the system with strange/invalid values, and see how the
system reacts
Live Tests – consists of letting people unrelated to the project to use the system and gathering their
opinions regarding the system afterwards
6.1 Approach to configuration and installation
Since the result of this project is a website, no installation or configuration by the end user is required.
7.
Item pass/fail criteria
Test name
Result
Description
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Normal test
OK
All the tests gave the expected
results
Component test
OK
All the tests gave the expected
results
Random test
OK
All the tests gave the expected
results
Faulty testing
OK
All the tests gave the expected
results
Live Test
OK
All the tests gave the expected
results
7.1 Installation and Configuration
The result of this project is a website that does not need to be installed or configured by the end user.
7.2 Documentation problems
As all the other documents were already done by the time of writing this document, there were no problems in
writing this document and determining test cases.
8.
Suspension criteria and resumption requirements
Most tests performed on the website are quite short and are performed quickly. Any discovered errors in website
implementation can be quickly resolved and the test results of unrelated parts of the website are unaffected.
Errors found in the web services will require a suspension of testing since more time is needed to fix them and
to redeploy the services on the server. All website tests that used the web service operations that contained
errors should be performed anew after removing all found errors.
9.
Environmental needs
9.1 Hardware


Laptop or Desktop Computer
Mobile Device (With QR Code Reader)
9.2 Software


Windows XP/Vista or Unix like OS
Browser (Mozilla, IE, etc.)
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
9.3 Other

10.
Internet connection
Test procedure
10.1 Test case specifications
10.1.1 User
10.1.1.1 Sign Up – User-QR Marks-001
Description:
Register the user within the system.
Test type:
Test type – “POSITIVE” (if the user has filled in all the required fields correctly.)
Test type – “NEGATIVE” (Because the username already exists or the visitor has not filled in all the required
fields)
Preconditions:
All the mandatory fields must be filled and username must be unique.
Input definition:
1. Fill in the user’s form (username’s field must be unique; otherwise the service returns an alert).
2. Click the button “Submit”
Output definition:
Expected output is “200 OK” from the service and the site should display all options available to registered
users. Notification about the new user should be added to the project’s twitter feed.
10.1.1.2 Modify Account – User-QR Marks-002
Description:
Registered user has the option to modify his/her profile by editing profile information.
Test type:
Test type – “POSITIVE” (User can modify their account by changing their information)
Test type – “NEGATIVE” (If a new username that is already taken is specified.)
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Preconditions:
The user must already exist in database.
Input definition:
1. Sign in at the website
2. Select Profile  Edit profile
3. Change user information
4. Click the button “Save Changes”
Output definition:
Profile changes reflected in the database and in the ProfileMy Profile page on the website.
10.1.1.3 Deactivate Account – User-QR Marks-003
Description:
Registered users have the option to deactivate their accounts.
Test type:
Test type – “POSITIVE” (Account deactivated)
Preconditions:
The user must already exist in database and supply the correct username and password for deactivation.
Input definition:
5. Sign in at the website
6. Select Profile  Edit profile
7. Enter the username and password
8. Click the button “Deactivate”
Output definition:
User is automatically logged out of the website and is listed as deactivated in the database.
10.1.1.4 Sign in – User-QR Marks-004
Description:
Check user credentials.
Test type:
Test type – “POSITIVE”
Preconditions:
User must be registered in database.
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Input definition:
1.
2.
User enters his/her username and password at the main page.
User clicks on the “Submit” button.
Output definition:
The user is signed in.
10.1.1.5 Sign out – User-QR Marks-005
Description:
To sign out of the system.
Test type:
Test type – “Positive”
Preconditions:
User must be signed in.
Input definition:
1.
The user selects “Sign out” from the main menu.
Output definition:
Sign out from the website.
10.1.1.6 Communicate with other users – User-QR Marks-006
Description:
Communicate with other users.
Test type:
Test type – “POSITIVE” (sending and receiving message from other user/player)
Preconditions:
Both users are registered within the system and the user sending the message is already signed in.
Input definition:
1. Select ProfileInbox from the main menu.
2. Select “Compose” option.
3. Write the message, select the recipient and click the “Send” button.
4. Recipient selects the ProfileInbox from the main menu and selects the new message.
Output definition:
Web service stores the message in the database. Messages are displayed to the receiving user.
10.1.1.7
Select a Game – User-QR Marks-007
Description:
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Select a desired game
Test type:
Test type – “POSITIVE” (User can select existing game)
Preconditions:
User must be signed in and desired game should exist in the database.
Input definition:
1. Select Game from the main menu.
2. Press “Select” for the desired game from the game lists.
3.
Output definition:
Web service retrieves all the information about selected game from the database and the information is
displayed to the user.
10.1.2 Creator-QR Marks
10.1.2.1 “Create Game”-QR Marks-008
Description:
To create a new game based on QR codes.
Test type:
Test type – “POSITIVE” (user can create successfully new game)
Preconditions:
User must be signed in on the website.
Input definition:
1. Select GamesCreate game from the main menu.
2. Select the desired game preference from the offered set of rules.
3. Select the locations for the QR Codes.
4. Enter the content of each QR code and keyword for each location.
5. Click the “Generate” button.
Output definition:
When the user selects the “Create game” option, game creation form is displayed. Web service stores the game
information in the database. QR codes with the content user specified are generated and displayed to the user.
Notification about the game creation is displayed on the project’s Twitter feed, and the game’s twitter feed if
one was specified.
10.1.2.2
Invite users to play a game – Creator-QR Marks-009
Description:
Invite a specific user to a private game.
Test type:
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Test type – “POSITIVE” (Invite successful)
Preconditions:
User must be signed in and trying to invite another user to a game they created.
Input definition:
1. When creating the game, select “Private” option for the game being created.
2. Select the users to be invited from the list.
3. After completing game creation, specified users will be invited to the game.
Output definition:
Specified users invited to the game.
10.1.2.3 Modify a Game – Creator-QR Marks-010
Description:
Change the game preferences.
Test type:
Test type – “POSITIVE” (Modification reflects successfully in the database)
Test type – “NEGATIVE” (Game is already played by at least one user)
Preconditions:
User must be the creator of the game.
Input definition:
1. Select GamesMy Games option in the main menu.
2. From the “Created games” list select the desired game.
3. Changes the parameters of the game and click to save changes.
Output definition:
Successful modifications reflected in the database.
10.1.2.4 Delete a Game – Creator-QR Marks-011
Description:
Delete the game.
Test type:
Test type – “POSITIVE”
Preconditions:
User must be the creator of the game.
Input definition:
4. Select GamesMy Games option in the main menu.
5. From the “Created games” list select the desired game.
6. Click “Deactivate Game” button.
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Output definition:
Game deactivation reflected in the database.
10.1.3 Player-QR Marks
10.1.3.1 Join a game – Player-QR Marks-012
Description:
Join a specific game.
Test type:
Test type – “POSITIVE” (Game is active (i.e., game end date not reached) and is either public, or the user was
invited to the private game)
Test type – “NEGATIVE” (Game is no longer active or is private)
Preconditions:
User signed in and trying to join an existing game.
Input definition:
1. Select “Games” from the main menu
2. Select “Join” for the desired game.
3. After reviewing game information click “Join game” button.
Output definition:
User successfully joined the game and the first location is displayed on the map.
10.1.3.2 Update player status – Player-QR Marks-013
Description:
To update game status and get the next location or finish the game
Test type:
Test type – “POSITIVE” (user achieves any target)
Preconditions:
User should be sign in and should be playing a game.
Input definition:
1. User signs in with existing username and password.
2. User playing game from available game.
Output definition:
User status will be upgraded as per user achieve any goal in the game.
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
10.1.3.3 Leave a game – Player-QR Marks-014
Description:
To leave a game
Test type:
Test type – “POSITIVE” (User Leave the game and save his/her status in database)
Preconditions:
User is jut playing a game.
Input definition:
1. Sign in as user/creator
2. User selects the game or joins an existing game.
3. User exit from current game and join a new game from list or log off from website.
Output definition:
User exit from game and its status store in database.
10.1.4 Visitor-QR Marks
10.1.4.1 Read general information – Visitor-QR Marks-015
Description:
To find out some information the user is interested in.
Test type:
Test type – “POSITIVE” (Information is shown on community page message when user/visitor click on
community tab).
Preconditions:
Information must be on community page.
Input definition:
1. Open the home page.
2. Click on community tab.
Output definition:
General information is shown on the community page.
10.2 Stress Test
Description
Result
QR Marks the Spot
Acceptance Test Plan
Version:
1.0
Date: 2010-01-11
Concurrency Level
Time taken for tests
Complete requests
Failed requests
Write errors
Keep-Alive requests
Total transferred
Requests per second
Time per request
Time per request
Transfer rate
11.
Responsibilities
11.1 Developers
All group members did all the test cases.
11.2 User representative
12.
Risks and contingencies
This website was tested with both Internet Explorer and Mozilla Firefox but we don’t know how it will behave
with other or older web browsers.
13.
Approvals
Name
Title
Date
yyyy-mm-dd
Signature