Test plan

Approach

Since there is no need to execute the tests in repetition by the client or the test team except for the purpose of having an application of good quality, manual tests will be used. But for information only there were some tests with Selenium on Chameleon sample applications and the results were that some elements were not accessible through Selenium API. Selenium seems to be a good tool for record/playback but may need improvements in order to be used for testing Chameleon applications. Under the given time constraint it is preferable to manually test this Web application.

Testing will follow the development phases but it is expected that the phases will be limited to a beta, a release candidate and a release phase.

Testing will occur on each supported browser except otherwise specified and use cases will be executed by one tester.

System requirements

The Web application will be tested on FireFox?, Internet Explorer and Safari. The latest release version of each browser will be used for the tests.

Features to be tested

The following table describes the features that will be tested.

Description	Browser(s) to test on
User login/authentication (login, layer management, map management)	all
Display/navigation of spatial data	all
Summarize data: buffer, boolean operations, proximity, summary of raster cell values by area	all
Locate/filter: quickzoom, filter	all
Report attributes	all
Upload for authorized	all
Data extraction tool	all
Add local content	all
Provide feedback	all
Access to non-spatial information	all
Right-side bar: legend tools bar	all
Links in left-side bar (zoomtoregion, layer/theme access)	all
List of regions and themes associated with extents	one
Documentation relates to application	one

Features not to be tested

The following feature(s) will not be covered by the tests:

• Application installation

Entrance/exit

Tests will be executed as soon as a functional application is available and will stop at the end date of the project or if there is no more critical bug (blocker, critical, major) and trivial bug (misspelling, cosmetic).

Data

To ensure that no data will be damaged or loss test data will be needed.

List of tests

Requirements

The requirements will be verified against the following criterias:

1. Correctness: The requirements must meet the user expectations and the technical specifications.

1. Completeness: The outline requirements must completely describe the technical system. This will encourage better planning and prevent future problems.

1. Consistency: Identify potential contradictions between the outlined requirements. One requirement must not contradict another requirement.

1. Testability: Each requirement must be testable. This leads ultimately to the QA/testing done in the project.

1. Feasibility: The requirements must be able to be realized on schedule, on budget, and with the resource and technology available.

1. Necessity: Each requirement must serve a specific goal.

[:Requirements_report:Requirements test report]

Use cases

• usecases.pdf : Use cases test

The use cases to test the functionalities listed in “features to be tested” section will be built and included in this section.

Test deliverables

A final report that will include a list of bugs found and this test plan will be delivered .