Testing Web Geoportal User Acceptance

RESTRICTED
CONTENTS
1.Introduction................................................................................................................................................1
1.1Purpose Of This Document...............................................................................................................1
1.2 REFERENCES..................................................................................................................................1
2. Project Scope...........................................................................................................................................1
2.1Development Framework..................................................................................................................2
2.2 User characteristics...........................................................................................................................3
2.2.1 Administrator...............................................................................................................................3
2.2.2 Sub-administrator.......................................................................................................................3
2.2.3 Super User..................................................................................................................................3
2.2.4 Normal User................................................................................................................................3
2.2.5 Publisher......................................................................................................................................3
3.0 Requirements Cross Reference Matrix..............................................................................................4
4.0Master Test Plan......................................................................................................................................20
4.1 Testing Approach............................................................................................................................20
4.2 Tools and Reports...........................................................................................................................21
4.2.1Interim Status Reporting...........................................................................................................21
4.2.2 Issue/Defect Reporting............................................................................................................22
4.2.3 Acceptance Test Summary Report........................................................................................23
4.2.4 Acceptance Test Final Report................................................................................................24
4.3 Features to betested..................................................................................................................25
4.4Criteria for test completion..............................................................................................................25
4.5 Criteria For Defect Categorization.................................................................................................26
4.5Environmental Needs.......................................................................................................................27
4.6Planning Risks And Contingencies................................................................................................28
4.7Test Tools..........................................................................................................................................28
5. Risks........................................................................................................................................................28
6.0 Abbreviations, Acronyms &Glossary.......................................................................................................29
RESTRICTED
i
RESTRICTED
1.Introduction
This document describes the detailed User test plan to test the
Geoportalsoftware. The document is in accordance with DRDO Standard for
Software Development(DSSD), Edition-2016.
1.1Purpose Of This Document

The purpose of this document is to outline the test strategy and overall test plan
to be followed for the software Web Geo-portal. This includes test methodologies,
traceability (from URS),resources required and estimated schedule.
1.2 REFERENCES
• Web Geo-portal – User Requirements Specification (URS)
• Web Geo-portal – Functional Requirements attached in RFP
• DRDO Standard for Software Development(DSSD), Edition-2016
2. Project Scope
The scope of the project is creation of Web Geo-portal ver.1.0 software to
be developed at DTRL. Web Geo-portal ver.1.0 is targeted for no dependency on
COTS software and will help in penetration of developed GIS tools to wider
spectrum of defence users. Provision of armed forces specific functionalities will
facilitate the users to exploit the big geospatial database.
The scope of this task is to make the geographical information/analysis
available with DTRL/End Users which is spatio-temporal in nature. All
functionalities will be available in a simplified web interface which should act as a
DSS or help in operational planning. The development of such platform should be
based on OGC standards. The main feature of such platform will be visualization
of spatial data, use of interoperable GIS web services, distributed analytical
functions, security of data etc.
To accomplish the above mentioned objectives, a spatial database must

be designed to accommodate and manage vector as well as raster data available
with DTRL. The spatial data upload in to the database must also be facilitated
RESTRICTED
User Acceptance Test Plan – Geo-Spatial Framework (Project DHARASTRA) 1
RESTRICTED
using suitable ETL tool. After generation of the spatial database using qgis, web
services generation is must to cater the functions such as.
• Data discovery – Provide search and discovery to geospatial data and

services using metadata [CSW – Catalogue service of Web]
• Data Visualization – Provide visualization images of the actual
geospatial data [WMS (Web Map Service), GWC (GeoWebCache),
WMTS (Web Map Tiling Service), SLD (Styled Layer Descriptor),
WMC (Web Map Context) etc.]
• Data Processing – Provide the processes for processing of geospatial
data [WPS – Web Processing Service]
• Data Access – Provide actual access to the geospatial data [WFS
(Web Feature Service), WCS (Web Coverage Service), GML
(Geographic Markup Language)]
2.1Development Framework
• Database – Postgre SQL

• Spatial Extension – PostGIS
• LDAP – Open LDAP/ Apache DS
• GIS Application Server – Geoserver
• Frontend – Open Layers, Leaflet
• Webserver – Apache Webserver
• Web Services – Java/J2EE
• Desktop GIS - QGIS
• Cache – GWC
• Proxy Server
• Desktop GIS Client – QGIS
• Cesium Globe
• Server OS : CentOS
RESTRICTED
RESTRICTED
2.2 User characteristics

2.2.1 Administrator
The Ultimate authority of entire application and has the rights to alter in the
database. Administrator is the person who validates the data and has the rights
to do application structural changes. Administrator has the rights to create/delete
user, reset password, assign the roles and responsibilities for every user.
Administrator has the rights to edit and update the Relationship tables specified
under user management module. Administrator responsibility will be assigned to
a suitable person from CAMS.
2.2.2 Sub-administrator
Sub-Administrator will be responsible to carry out the role of administrator for his AOI
and its users along with attribute data editing and publishing.
2.2.3 Super User
The super users are the top officials who have the access to all kind of
computational intensive geospatial analysis as well as dashboard visualization for
their AOI.
2.2.4 Normal User
The normal users are the users who have been assigned with the rights to view
the application and can perform basic map functions along with various GIS
Analysis over the data for which they have access privilege.
2.2.5 Publisher
Publisher will be allowed to create/edit/delete the spatial data as well as

publish/un-publish it over/from the application server.
RESTRICTED
RESTRICTED
3.0 Requirements Cross Reference Matrix
S.No Cross Functional Acceptance test detail

Reference Requirement
from URS
1. UR1 Web Geoportal Testing of following implemented web for
Geoportal:
a) Based on OGC standard and Platform
independent.
b) Cross browser.
c) Cross device (desktop, mobile, tablet).
d) Platform should be able to work in
Intranet mode only without any need to
refer to online resources.
2. UR2 Login Testing of following implemented for login:
a) Authentication by LDAP.
b) The system must facilitate access
control by binding users to Raster,
Vector and its attribute for a particular
geographic area.
c) Geographic area of interest control (for
viewing or downloading purpose) shall
be up to n-1 levels for each user.
d) Session should not allow same user to
login simultaneously.
e) Change password.
f) Login attempts for 3 times then after a
lock will be applied for the current day.
g) User login-logout lock (browser).
h) Virtual keyboard option.
i) Captcha to prevent bot attack
RESTRICTED
RESTRICTED
3. UR3 Home Page Testing of following to display of default on

Home Page.
a) Menu
b) Logo(Organization)
c) Login-Password GUI
4. UR4 Basemap (WMS) Testing of following to display base map by

default on Home Page of the user
a) Vector basemap.
b) Satellite map
c) Hybrid map
5. UR5 Basic GIS tools a) Zoom IN: Test functionality to display by

default under a map module. Zoom In tool
should be provided such that user can
zoom in to a particular area of interest on
the map. Zoom In function will be executed
in the map area and zoom in on the center
of the data frame at the ratio of 1:2 scale
b) Zoom Out: Test functionality to display by
default under a map module. Zoom Out
tool should be provided such that user can
zoom out from a particular area of interest
on to the map. Zoom Out function will be
executed in the map area and zoom out on
the center of the data frame at the ratio of
2:1 scale.
c) PAN: Test functionality to display by
default under a map module. PAN tool
should be provided such that user can
hold the map and move to the particular
map area. It shifts the view without
changing the viewing direction.
RESTRICTED
RESTRICTED
d) Zoom to box: Test functionality to display

by default under a map module. Zoom to
Box tool should be provided such that user
can zoom in to a particular area of interest
by drawing a box. This tool will facilitate
user to define a box and can zoom in to
the box extent.
e) Zoom to scale: Test functionality to display
by default under a map module. Zoom to
scale tool should be provided such that
user can zoom in to a particular scale. Pre-
defined map scales will help user to switch
between the scales and can view the map
according to the scale extent. User can
zoom to scale in order to work at that
particular scale
f) Overview map: Test functionality to display
by default under a map module. Map
Overview tool will allow users to see
whether in which part of the map they are
working on or zoomed to. It should consist
of a small window displaying the entire
map and the extent where the user is
working on.
g) Navigation history: Test functionality will
allow user to go to the preceding zoom
level as well as the next view of the zoom
level. A user can toggle between the
previous zoom level on which they worked
on and the next zoom level in the map
area
h) Full screen map: Testing functionality to
RESTRICTED
RESTRICTED
help user to view the map in full screen. In

a full screen view, users will get more
viewing area for map at that scale and only
basic tools like Zoom In, Zoom Out and
Pan will be active
i) Scale bar: Testing functionality to a scale
bar is a basic GIS tool which facilitates
user to know the scale of the map. A map
scale bar is the representation of distance
on a map and the corresponding distance
on ground. It will provide user with
important information regarding linear
relations on the map
j) North Arrow: Testing functionality to just
provides user with the direction on the
map and gives the direction as per
magnetic north as per the projection
system used
k) Testing functionality to selection by feature
tool should facilitate user to select the
feature class of their own area of interest
and get their attribute information.
Selection by feature should be done in two
ways:
 Single feature select – allows user to
select a particular feature and get the
attribute details.
 Selection by area – allows user to get
attribute information of all the features
falling within the selected area.
l) Information tool( i tool):

It should facilitate user in identifying an
underlying feature/features by clicking on it
RESTRICTED
RESTRICTED
and respective attribute of the feature will

be displayed in the attribute table
m) Mouse position (Coordinate position):
Testing functionality to mouse position
simply gives user the coordinates of that
particular point where the mouse pointer is
in the status bar. A user can know the
Latitude, Longitude, Mil GR with letter and
Map sheet no. as per DSM/ESM of a point
of interest by simply moving the mouse
pointer on it
18. UR6 Attribute query Testing of following to query on single attribute
parameter.
a) Attribute query tool facilitates user in
querying the layer in order to filter the
information upon provision of the attribute
criteria. This tool will facilitate with three
types of query modes:
 Basic query: It is basically querying a
layer on a single attribute parameter.
User has to select attribute and the
respective value (either by entering or
by choosing) on which user wants to
perform the query.
 Advanced query: It is basically querying
the layer on multiple attribute
parameters. Here user can select more
than one attribute (combination of
attribute parameters) along with
respective values to perform the query.
 Query based on administrative
boundaries and respective rights: This
query module would be available to the
users for querying the data based upon
administrative boundaries as well as
virtual layers.
b) Testing functionality to query based on
multiple attribute parameters.
c) Testing functionality to query based on
RESTRICTED
RESTRICTED
administrative rights.
19. UR7 Bookmark query Testing functionality to facilitate users to save

their queries and bookmark it and it should
facilitate user to view the query and edit it as
and when required and modify it.
20. UR8 Routing Testing of following implemented routing
algorithms:
a) This tool should trace the route between
any two points or landmarks upon
selection by user. It should help user in
finding the shortest route. The routing
should be tested within following
environments:
a. Between two points. (can also be
performed on a DEM)
b. Between two landmarks.
c. Nearest neighbors with respected
routes. (Pre-defined area).
d. Use of stop/barrier to find alternate
route
e. Use of one way/two way
f. One location to all shortest route to a
layer within defined distance
21. UR9 Measurement Testing of functionality for measuring distance

tools and area on map. Using this tool, user can
know the distance between two points or an
area covered between set of points (part of
polygon) as per the defined units. Measure
tool should consist of two sub-tools:
 Measure by distance. (distance
between two points)
 Measure by Area. (Area enclosed by set
of points)
 Measuring distance ellipsoidal/planner
RESTRICTED
RESTRICTED
Testing results should be displayed in the tool

bar itself in the same units that has been
chosen from the given list by the user.
22. UR10 Go to XY Testing of functionality of Go to XY:
a) Set the co-ordinate position and reach
that location.
b) Get the coordinate position on mouse
click.
 Go to XY tool should help
user to reach the location on
giving the coordinates/ place
name/ grid location of that
point.
 Users should enter X and Y
values in the respected fields
as per the projection and the
resultant location will be
displayed on the map.
 User can also get the X and Y
values of a location by just
clicking on the map.
 Jump to Mil GR
23. UR11 Linear Testing of functionality to know the facilities

Referencing within a predefined distance with reference to a
linear transect.
24. UR12 Attribute data Testing of following attribute data:
display a) Column based filters
b) Grid should be read only.
c) Column statistics.
d) Zoom to feature.
e) Highlight feature on selection.
RESTRICTED
RESTRICTED
f) Export of attribute data based on user

current extent/ complete data)
25. UR13 Spatial Analytics Testing of following functions of Spatial

Module Analytics Module:
a) Buffer (Point, Line, Polygon)
b) Disjoint, Intersects, within, Overlaps,
Contains, Covers, Covered By, within a
distance, Equals. (On layers or user-
defined area)
26. UR14 Layer Testing of layer manager: layer manager

management should provide with listing of layers along with
legend as per category. The layers will be
visible based on administrative rights.
 The layer window should have an i-tool
for getting layer information.
 It should also have a settings tab
allowing user to set the opacity of the
layer, Dynamic labeling, Layer turn
on/off, Layer ordering, Theme based
categorized symbology and Layer
Grouping.
 Placing label(Text) using attribute of
feature with symbology, orientation,
rotation and alignment
 It show layer name and its authorized
( partial restricted) attributes as per
authentication of login user by
authentication tools.
 Swiping(scroll bar) of top layer for
part/full visibility
RESTRICTED
RESTRICTED
 Administrative boundary based layers
27. UR15 Search Testing of following search functioality

a) Location search
b) Fuzzy search on layers:-
Search tool will help user to search any
location on the map or with just a
keyword can search through the layer’s
attributes available. The search tool will
be based upon the fuzzy logic. Search
tool will also allow layer search (a single
layer, multiple or all layers) based upon
user requirement. This will activate
search among all the layers’ user wants
to search their keyword for. Search a
feature in any layer by begins with few
character of attribute table and one may
zoom to that searched feature.
28. UR16 Map Print Testing of map print functionality

a) Based on current view extent. (only
selected layers)
b) Printing should be template based and
symbology accuracy should be in
millimeters for print purpose.
c) Printing module should have options like
Map layout, DPI and Map orientation)
d) Patterning and finishing with all
available legends.
29. UR17 Reset Map Testing functionality to facilitate user to reset

map to last session or default status.
30. UR18 Import Testing functionality to allow user to add
RESTRICTED
RESTRICTED
external layers using one of the following

options like CSV, .shp, geojson, kmz, KML,
GML formats for current user session. User
can only view their imported data without any
modification to the actual map and will be
session based. On termination of session, the
imported data will be removed automatically.
31. UR19 Logout Testing functionality to log out from the current
operation of the interface. The control goes to
the portal home page after saving the last
configuration detail.
32. UR20 Temporary Testing of following create/add external layers
Overlay of popular format from client machine, to map
canvass and gives capability to edit/digitize
them:
 Tools to mark point, line and polygon as
overlay at client end
 Defining symbology of point using
svg/png or sld files. Color, thickness and
style in linear feature and boundary
polygon. Fill color with transparency in
polygon
 Edit, undo, redo, move, copy options
 Placement of features with defined
Symbology
33. UR21 Editing and Testing functionality of Editing will be based on

versioning of editor role and validation of data will be based
spatial data using
QGIS on validation role.
34. UR22 Temporal data Testing functionality for Temporal data
visualization visualization option will allow user to visualize
the temporal raster/vector data through scroll
RESTRICTED
RESTRICTED
bar in an animated fashion

35. UR23 Admin Testing functionality for Administrator panel
Panel/User will be made available to the admin user to
Management
assign rights and roles to other users.
Administrator will be able to create users and
manage user rights and also entire portal
configuration will be managed by administrator
using the admin panel. It will allow admin user
to create or edit new or existing departmental
users. Admin user will be able to manage
access to categories, modules, information
and access levels for each departmental user.
User Characteristics:
Admin – An admin will be able to create or
update existing information through admin
panel. Admin will have an access to
dashboard for performing the following tasks:
 Activate – Deactivate/ delete User / Unit /
Organization
 Reset password
 Assign and Manage User / Unit / Departments to
Organization
 Rename/modify Department / User / Unit
 Assign Category to Department / User / Unit
 Assign Module/functionality to Department /
User / Unit
 Assign Users to Department / User / Unit
 Assign Access of Theme to Department / User /
Unit
Sub Admin – A sub admin will be responsible
for managing usersof his unit.Sub admin will
have an access to the similar dashboard as to
a admin but withdifferent rights for performing
RESTRICTED
RESTRICTED
following tasks:
Filling the metadata information of the
categories assigned to his unit
(Note: Metadata information includes columnar
data such as column name, column type,
column data type etc. on which labelling,
styling will be done)
Managing access of information for the Users /
Units allocated to the Department.
 Assign Category(normal/super/publisher)
 Assign Module
 Assign Metadata
 Assign Access (AOI based)
 Reset password
36. UR24 Raster and vector Testing for functionality to support for raster
data import to and vector data import to database in all GDAL
database
supported formats.
37. UR25 Projection Testing of following functionalities for
projection:
a) Multiple projections (as per EPSG
code) to be supported
b) Data from multiple projections to be
saved in database in a default
projection.
c) Publishing of data in default projection.
38. UR26 Symbology Testing for functionality to supportcomposite

symbology.
39. UR27 User Activity log Testing to keep a track on all the activities at
portal by every user via generating the log.
40. UR28 SSL encryption Testing to support https for security purpose.
SSL (Secure Socket Layer) is a tunneling
RESTRICTED
RESTRICTED
protocol that works at the transport layer. It

provides encryption, authentication and
integrity verification of data, and does so
by means of digital certificates. A digital
certificate is an electronic document which
confirms the identity of an entity (a user,
server, a Unit, a program on a client, etc.)
It includes following steps.
 Installing the certificate on an

authentication server.
 Linking it with the host.
41. UR29 Client Side Testing to support to client side free

Marking Tool drawing over AOI(area of interest) and
save
42. UR30 Security Setting Testing of following Security setting:
 Session cookie –HTTP only –disabled
 Options method- disabled
 HTTP Header Vulnerabilities
i. X Frame Options Response heads-Incl
ii. X-Xss Protection header-define
iii. X-Content-Type-Option Header-Set
Protection
 Version of software should not be
disclosed
 All ports should be closed except SSL
 Special character input should be
prohibited in the input box of application
except password creation
 Functionality of remembering user input
in the various forms within the client
RESTRICTED
RESTRICTED
and browser should be disabled in the

application
 Program should not contain any key
logging mechanism
 Source code should not be potentially
unfinished( indentation & comments)
and poorly validated(Quality)
43. UR31 Dashboard Testing of following Dashboard functionality:

a) Graphical summarization of data
b) Choice of multiple graphs.
c) Comparison between administrative
boundaries.
44. UR32 GPS Tracker Testing functionality to display GPS

coordinates of vehicles on map canvas.
45. UR33 ETL Testing functionality for ingestion of legacy
Vector data into database.
46. UR34 Retrieval of Testing functionality for retrieval of user
raster/vector data privilege specific raster/vector data.
from database
47. UR35 Almanac data Testing for visualization of almanac data in
various graphical formats.
48. UR36 Raster Testing functionality for image mosaicing,
processing as rectification, enhancement & change
WPS
detection(over temporal images)
49. UR37 Measurement of Testing functionality for measurement of
Distance/Area Azimuth angle, Horizontal, Vertical, Diagonal,
and Azimuth
Surface distance and planner/surface area.
50. UR38 Urgent Info. Testing functionality for Admin to disseminate
Dissemination Info. Which will be displayed on all designated
client machines’ map canvass.
51. UR39 Coordinate Testing functionality for Coordinate converter
Converter
RESTRICTED
RESTRICTED
long /lat to DSM GR and vice versa.

52. UR40 3D visualization Testing the functionality to toggle to 3D
visualization of Terrain for Map Canvass/ User
specific area having all data available in last
session of 2D and vice versa
53. UR41 Distance/Area Testing functionality to measure Horizontal,
measurement Vertical, Diagonal, Surface distance and
planner/surface area.
54. UR42 Slope map Testing functionality to generate and drape
the slope map for AOI.
55. UR43 Aspect map Testing functionality to generate and drape
the aspect map for AOI.
56. UR44 Relief color Testing functionality to generate and drape
coded the color coded density slicing of DEM.
57. UR45 Terrain profile Testing functionality to generate and display
the elevation profile along a line feature.
58. UR46 Best path Testing functionality to generate and display
best path between two points based of
up/down slope constraint
59. UR47 LOS Testing functionality to generate and display
line of sight between 2 points( visible & non
visible line segments will be displayed in two
colours).
60. UR48 View shed Testing functionality to generate and display
view shed of 120/360 degree from the
observer point
61. UR49 Dome Analysis Testing functionality for rendering of the dome
specifying the visibility/non visibility of the
terrain with different colors from the specified
point (centre of Dome), at the specified input
range and height of observer.
62. UR50 Predefined path Testing functionality to fly through along the
RESTRICTED
RESTRICTED
fly through predefined path.

63. UR51 Temporal data Testing to visualization of temporal data in
visualization animated fashion.
64. UR52 Cut and Fill Testing functionality to volume estimation for
Cut/Fill of a polygon.
65. UR53 Varying of light Testing functionality to see the sun angle and
intensity/ sun light intensity effect on terrain defined by hour
angle
and month slider and visualization of moon
position (information).
4.0Master Test Plan

This master test plan identifies overall rules and processes that need to beadhered to
during the testing process.
• Every artefact (feature/functionality) of Geo –Portal shall be tested.
• Every defect shall be prioritized as per the standard priority classification High,
Moderate, Low
• Functional testing and workflow testing are carried out independently.
4.1 Testing Approach

The purpose of the acceptance testing is to determine whether or not the software
system has met the specified requirements. The main purpose of this test is to evaluate
the system's compliance with the user requirements and verify if it has met the required
criteria for delivery to end users.
Each of the artefacts shall be tested in three levels i.e. Unit, System and Acceptance
testing.
Unit Testing is carried out by the developer. Test deliverables include test case list,
sample output and defect information and these are reviewed by team lead.
System Testing is carried out by team lead and testing associate with developer’s
assistance. This shall be carried out only after all the critical issues identified during
RESTRICTED
RESTRICTED
unit test phase are resolved. Integration tests typically consume major portion of
testing efforts owing to its nature to destabilize overall product stability.
Acceptance Testing
The final software will be accepted for deployment/delivery only after it passes the unit
testing and integrated testing over test bed hardware. Following are the steps in the
acceptance test process :
A.Complete Acceptance Test plan for baseline reference

There should a complete test plan for starting the acceptance test for the
software. The acceptance test plan document will serve the reference
document for complete execution of the acceptance test.
B. Acceptance Test cases

The test cases for various acceptance tests will be prepared covering input
and output data and mutually agreed test completion criteria. The tools and
techniques for executing the test cases will be identified and recorded.
C. Acceptance Tests
There will be two type of acceptance tests for the Geo portal Software -
Customer Acceptance Testing and User Acceptance Testing which will be
performed by DTRL and CAMS, Military Survey respectively in their operational
field(test bed) and actual field(data centre) for compliance of all requirements.
At any instance, the status of the testing may be generated as per the format mentioned
in section 4.2.1. Acceptance Test summary report and Acceptance Test Final Report
formats are mentioned in sections 4.2.3 and 4.2.4respectively.
4.2 Tools and Reports

4.2.1Interim Status Reporting
Following is the sample interim status report for the test.

INTERIM TEST STATUS REPORT
Tester Names: Date:
RESTRICTED
RESTRICTED
Functional Number of Subtotal of Subtotal Percent Number of

tests executed tests of tests Failed tests not
Areas passed failed tested
Functionalities as
per High priority
Functionalities as
per Moderate
priority
Functionalities as
per Low priority
Non Functional
Requirements
4.2.2 Issue/Defect Reporting
The test problem reporting process includes
• Identifying the problem

• Creating the software change request (SCR) if any
• Assigning a problem status, priority and severity
• Monitoring the SCR resolution
• Verifying the results
• Closing resolved SCRs
• SCR status
ISSUE/DEFECT REPORT
Tester Name: Software Version:
User Acceptance Preliminary Severity Critical/Major/Minor/Trivial

Test ID Assessment:
Nature of Priority Low/Medium/High

Issue/Defect:
What occurred:
RESTRICTED
RESTRICTED
How did it occur:
When did it occur:
Describe how to
reproduce the
error:
SCRINFORMATION
AssignedSCR Severity: Status:

Number
Open/Close
4.2.3 Acceptance Test Summary Report
This report provides the client with the information to formulate an “accept” or “reject”
decision. The information within the report includes
• Total number of tests

• Subtotal number of tests executed
• Subtotal of number passed
• Subtotal of number failed
• Severity of failed test issues grouped by low, medium, or high
• Subtotal of number not tested
• Subtotal of tests no longer applicable
• Total number of SCRs
• Number of Open SCRs
• Number of SCRs not tested
• Number of unresolved SCRs
• Number of SCRs failed
• Number of SCRs resolved and tested
• Number of Closed SCRs
• Subtotal by level and open/closed status
RESTRICTED
RESTRICTED
• Number of software deliveries during testing
ACCEPTANCE TEST SUMMARY REPORT

Functional Tot Number Percent Subtot Subtot Percent Number Total of
Areas al of tests Complet al of al of Failed of tests tests no
No. execute e tests tests not longer
of d passed failed tested applicable
Tests
Functionalit
ies as per
High
priority
Functionalities
as per
Moderate
priority
Functionalities
as per
Low priority
Non
Functional
Requirement
4.2.4 Acceptance Test Final Report
The Acceptance Test Final Report is the detailed record of acceptance test
activities. The testing performed the pass/fail status of each test case, and
discrepancies or issues found are recorded. At a minimum, the Acceptance Test Final
Report includes
• Software name
• General description of the system test effort
• Details for each test along with traceability to the requirements
• Acceptance tester names and dates
RESTRICTED
RESTRICTED
• List of unresolved software defects and issues and their effects on the
system, mitigation of the risks, or work-around.
ACCEPTANCE TEST FINAL REPORT
Software Name: Geo Portal Date:
General description of the acceptance test effort:
Unresolved Defects
Issue/Defect Impact (H, Risk Work Around

M, L) Mitigation
(If known)
(If known)
4.3Features to betested
All the functional requirements (ref para 3.0) with their program module and UI.
4.4Criteria for test completion
Unit Testing Unit Testing is considered complete once the unit tests
deliverables viz. test cases, sample input and output data
used and tests are carried out successfully by developer.
Developer need to share information about the defects
found and resolved as well. Additionally, developer also
needs to share information about the limitations if any.
System Testing System Testing is considered complete if all the components

of the integrated block of code as well as all remaining
components of the system are performing with reasonable
level of stability. A program may have up to one Major
severity defect as long as it do not impede testing of the
RESTRICTED
RESTRICTED
program (ie., there is a work around to achieve the desired

output).
Acceptance Acceptance Testing shall be considered complete if and only

Testing if all open critical defects are corrected and verified by the
end-user test representative once the agreeable closing
criteria is achieved as defined in the test cases. At the
maximum one major defect is tolerated provided that a work
around exists to achieve the desired result.
4.5 Criteria For Defect Categorization

Defect Priority
Priority can be categorized into

Priority Level Description
High Must be fixed in any of the upcoming builds but should be included
in release
Moderate May be fixed after the release or in the next release
Low May or May not be fixed at all
Defect Severity
Defect Severity or Impact is a classification of software defect (bug) to indicate the

degree of negative impact on the quality of software.
To measure the degree of impact that the defect/bug has on the operation of component
or system defect severity is classified into following classes:
S.no Class Symbol Description
RESTRICTED
RESTRICTED
1. Critical S1 • Affects critical functionality or critical data.
• Have no work around.
• e.g. Unsuccessful installation, complete failure of a

feature
2. Major S2 • Affects major functionality or major data.
• Has a workaround but is not obvious and is difficult.
• e.g. A feature is not functional directly from one

module but can be indirectly accessed if 10
complicated steps are followed in other module.
3. Minor S3 • The defect affects minor functionality or non-critical

data.
• Has an easy workaround.
• Example: A minor feature that is not functional in one

module but the same task is easily doable from
another module.
4. Trivial S4 • The defect does not affect functionality or data.
• It does not even need a workaround.
• It does not impact productivity or efficiency. It is

merely an inconvenience.
• Example: Petty layout discrepancies,
spelling/grammatical errors.
4.5Environmental Needs
To perform the overall testing at all levels following elements are required;
a) Geo-portal Hosted in test bed/Data Center.
b) Server Operating System: Centos.
c) Client Operating System: any release in last two years for Windows/Linux for
desktop and ANDROIDfor handheld device
RESTRICTED
RESTRICTED
d) Desktop ClientMinimum Hardware: I3 processor with 4GB RAM, 1GB graphics

card and 19” monitor.
4.6Planning Risks And Contingencies
S.No Probable Risk Contingency
1. Availability of Relevant Data Open Source/project generateddataset will be

used as Input for testing various functionalities
of the software.
2. Administrative Right with user in OS Dependency on system administrator will be
environment there.
4.7Test Tools
Each build must be thoroughly tested by the development partner using appropriate
testing tools and test cases.
5. Risks
The following are typical, general overall acceptance test risks
A. Insufficient test time
• Risk
If the amount of time available is too short, the acceptance test team may
not have enough time to complete acceptance testing or perform
regression testing.
• Mitigation
Develop a critical path of tests, prioritized by importance.
B. Incomplete requirements
• Risk
RESTRICTED
RESTRICTED
May result in insufficient testing of the system.
• Mitigation
Use the traceability matrices to track the testing/requirements relationship.
C.A test environment that is not the same as the production environment
(final deployment environment)
• Risk
May prevent the detection of some defects and issues.
• Mitigation
Note the differences and work to have them as close as possible.
6.0 Abbreviations, Acronyms &Glossary
Abbreviation Description
DB Database
GIS Geographic Information Systems
LDAP Lightweight Data Access Protocol
GWC GeoWebCache
WCS Web Coverage Service
WFS Web Feature Service
WMS Web Map Service
WMTS Web Map Tiling Service, ,
RESTRICTED

Testing Web Geoportal User Acceptance

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Testing Web Geoportal User Acceptance

Uploaded by

Copyright:

Available Formats

RESTRICTED

1.1Purpose Of This Document

To accomplish the above mentioned objectives, a spatial database must

• Data discovery – Provide search and discovery to geospatial data and

• Database – Postgre SQL

2.2 User characteristics

2.2.3 Super User

2.2.4 Normal User

Publisher will be allowed to create/edit/delete the spatial data as well as

3.0 Requirements Cross Reference Matrix

S.No Cross Functional Acceptance test detail

3. UR3 Home Page Testing of following to display of default on

4. UR4 Basemap (WMS) Testing of following to display base map by

5. UR5 Basic GIS tools a) Zoom IN: Test functionality to display by

d) Zoom to box: Test functionality to display

help user to view the map in full screen. In

l) Information tool( i tool):

and respective attribute of the feature will

19. UR7 Bookmark query Testing functionality to facilitate users to save

21. UR9 Measurement Testing of functionality for measuring distance

Testing results should be displayed in the tool

23. UR11 Linear Testing of functionality to know the facilities

f) Export of attribute data based on user

25. UR13 Spatial Analytics Testing of following functions of Spatial

26. UR14 Layer Testing of layer manager: layer manager

 Administrative boundary based layers

27. UR15 Search Testing of following search functioality

28. UR16 Map Print Testing of map print functionality

29. UR17 Reset Map Testing functionality to facilitate user to reset

external layers using one of the following

33. UR21 Editing and Testing functionality of Editing will be based on

bar in an animated fashion

38. UR26 Symbology Testing for functionality to supportcomposite

protocol that works at the transport layer. It

 Installing the certificate on an

41. UR29 Client Side Testing to support to client side free

and browser should be disabled in the

43. UR31 Dashboard Testing of following Dashboard functionality:

44. UR32 GPS Tracker Testing functionality to display GPS

long /lat to DSM GR and vice versa.

fly through predefined path.

4.0Master Test Plan

• Every artefact (feature/functionality) of Geo –Portal shall be tested.

4.1 Testing Approach

A.Complete Acceptance Test plan for baseline reference

B. Acceptance Test cases

4.2 Tools and Reports

Following is the sample interim status report for the test.

Tester Names: Date:

Functional Number of Subtotal of Subtotal Percent Number of

4.2.2 Issue/Defect Reporting

The test problem reporting process includes

• Identifying the problem

Tester Name: Software Version:

User Acceptance Preliminary Severity Critical/Major/Minor/Trivial

Nature of Priority Low/Medium/High

How did it occur:

When did it occur:

AssignedSCR Severity: Status:

4.2.3 Acceptance Test Summary Report

• Total number of tests

• Number of software deliveries during testing