Team Braintrust
Test Plan
for
Highly Accurate Mobile Device Positioning
Based on Wi-Fi Signals
Revision History
DATE
REV AUTHOR
DESCRIPTION
03/02/2011
A
Sam Gottfried
First Draft
05/06/2011
B
Sam Gottfried
Final Draft
Table of Contents
1.
Introduction 2
Establish Signal Strength Baselines by seeding data into the database............................. 2
Test Plan Objectives .............................................................................................................................. 2
2.
Scope
2
2.1. .............................................................................................................................. Database Seeding
...................................................................................................................................................................... 2
Establishing Wi-Fi Device Locations ............................................................................................... 2
Locating an End User Device .............................................................................................................. 2
2.4. Self Learning and Self Healing.................................................................................................. 2
Test Strategy
2
3.1. System Test ...................................................................................................................................... 2
Performance Test .................................................................................................................................. 3
3.4. Automated Test .............................................................................................................................. 3
3.5. Stress and Volume Test ............................................................................................................... 3
3.6. Recovery Test .................................................................................................................................. 3
3.7. Documentation Test ..................................................................................................................... 3
3.8. User Acceptance Test ................................................................................................................... 3
4.
Environment Requirements 3
5.
Test Schedule 3
6.
Control Procedures 3
6.1 Reviews .............................................................................................................................................. 3
6.2 Bug Review meetings .................................................................................................................... 3
6.3 Defect Reporting ............................................................................................................................. 3
7.
Functions To Be Tested 3
8. Responsibilities 3
1. Responsibilities ................................................................................................................................. 3
Deliverables 3
10. Suspension / Exit Criteria 3
Resumption Criteria
Dependencies
3
3
Personnel Dependencies..................................................................................................................... 3
Software Dependencies ....................................................................................................................... 3
12.3 Hardware Dependencies ........................................................................................................... 3
Test Data & Database............................................................................................................................ 3
Risks 3
13.1. Schedule ......................................................................................................................................... 3
14. Tools 3
Documentation 3
1. Introduction
Team Braintrust is developing a highly accurate mobile positioning system that will use Wi-Fi signal
strengths to determine the location of a device.
The system will be capable of the following:
·
Establish Signal Strength Baselines by seeding data into the database
·
·
·
Establishing Wi-Fi device locations by entering in the GPS location of a Wi-Fi device.
Locating an end user device
Self learning and self healing (lower priority)
1.1.
Test Plan Objectives
This Test Plan for the Wi-Fi device positioning system supports the following objectives:

Define the activities required to prepare for and conduct System and User Acceptance
testing.
Communicate to all responsible parties the System Test strategy.
Define deliverables and responsible parties.
Communicate to all responsible parties the various Dependencies and Risks



2. Scope
2.1. Database Seeding
The data will be collected by the inSSIDer application on a variety of laptops all running the
inSSIDer application on Windows. This data will be collected using a variety of patterns for
seeding data from a room, such as collecting from the center, collecting data around the edges
of a room, and “zig-zagging” the room. The data will then be seeded to the database.
1.2.
Establishing Wi-Fi Device Locations
We will seed GPS data into the database for each of the Wi-Fi devices in order to better
determine where the mobile devices are.
1.3.
Locating an End User Device
Once the database is seeded, we will be able to send data to our service and retrieve a result
that should indicate where the mobile device is located.
2.4. Self Learning and Self Healing
We will internally increase the confidence of an access point in order to test that self-learning
and self-healing works in our system. In doing this, we should get a higher confidence that a
device is in the location it is at.
1.
Test Strategy
The test strategy consists of a series of different tests that will fully exercise the Wi-Fi positioning
system. The primary purpose of these tests is to uncover the systems limitations and measure its
full capabilities. A list of the various planned tests and a brief explanation follows below.
3.1. System Test
The System tests will focus on the behavior of the Wi-Fi positioning system. Each feature will
be executed against the system. The system tests will test the integrated system and verify
that the system meets the requirements defined in the SRS document.
1.1.
Performance Test
Performance tests will be conducted to ensure that the response time for the system does not
take excessively long. There is no expected metric for this, since ZOS has stated that
accuracy is a higher priority than response time. This testing will be able to provide a figure for
how long our system will take to complete a request.
3.4. Automated Test
A suite of unit tests will be developed using the Visual Studio Team Test Unit framework.
These unit tests will test our internal data structures, seeding data to the database, as well as
retrieving it, and our location finding algorithms.
3.5. Stress and Volume Test
Stress testing will be conducted by adding large amounts of data to the database (via seeding)
and also by making several requests to the system.
3.6. Recovery Test
We will run tests to make sure that the system behaves properly when the server or the
database goes down.
3.7. Documentation Test
Tests will be conducted to check the accuracy of the user documentation. These tests will
ensure that no features are missing, and the contents can be easily understood.
3.8. User Acceptance Test
At the end of each evolution, ZOS will perform acceptance testing to insure that our system
meets the requirements agreed upon in the SRS, as well as their own expectations of the
system.
4. Environment Requirements
We will need a system with IIS that is running Windows XP or later.
5. Test Schedule




Unit test internal data structures
Week 11
Unit test database seeding and begin integration testing
Week 12
Unit test location algorithms and continue integration testing
Week 13
Test schedule for Evolution 2 will be added based on Evolution 1 testing

6. Control Procedures
6.1 Reviews
All documents will be reviewed before the team and the sponsor commit to them.
There will be code reviews every week on Tuesdays during our regularly scheduled meetings.
6.2 Bug Review meetings
Bug Reviews will follow the code reviews at our meetings.
6.3 Defect Reporting
FogBugz will be used to report defects found in the project.
7. Functions To Be Tested
The following is a list of functions that will be tested:
·
Seeding data into the database
·
Adding WiFi Device locations
·
Locating a mobile device including
o
Neural Network algorithm
o
Triangulation
8. Responsibilities
1. Responsibilities
8.
Test Lead
Ensures the overall success of the test cycles. He will
coordinate weekly meetings and will communicate the
testing status to the project team.
Testers/Developers
Responsible for performing the actual system testing.
ZOS
Responsible for performing acceptance testing
Deliverables
Deliverable
Responsibility
Completion Date
Develop Test cases
Test lead (Sam)
03/14/2011
Test Case Review
Developers/Testers
03/15/2011
Develop Automated test suites
Developers/Testers
ongoing
Execute manual and automated tests
Developers/Testers
ongoing
Complete Defect Reports
Test Lead (Sam)
03/21/11
Document and communicate test
status/coverage
Test Lead (Sam)
Weekly
Final Test Summary Report (for E1)
Test Lead
03/21/11
10. Suspension / Exit Criteria
If any defects are found which seriously impact the test progress, the QA manager may choose to
suspend testing. Criteria that will justify test suspension are:
 Source code contains one or more critical defects, which seriously prevents or limits testing
progress.
 Assigned test resources are not available when needed by the test team.
11.
Resumption Criteria
If testing is suspended, resumption will only occur when the problem(s) that
caused the suspension has been resolved. When a critical defect is the cause of
the suspension, the “FIX” must be verified by the test department before testing
is resumed.
12.
Dependencies
12.1
Personnel Dependencies
The team requires experience testers to develop, perform and validate tests. These
The test team will also need people from ZOS to perform acceptance testing.
12.2
Software Dependencies
The source code must be unit tested and provided within the scheduled time outlined in the
Project Schedule.
12.3 Hardware Dependencies
Hardware has to be up and running
12.3
Test Data & Database
Test data & database should also be made available to the testers for use during testing.
13.
Risks
13.1. Schedule
A slip in the schedule in one of the other phases could result in a subsequent slip in the test
phase. Close project management is crucial to meeting the forecasted completion date.
14. Tools
Visual Studio Team Test will be used. All developers/testers will learn how to use this system.
15.
Documentation
The following documentation will be available at the end of the test phase:


Test Plan
Defect reports