Testing a geoportal 

 December 1, 2007

The test process

Motivation

Many authorities and companies that work with spatial information are now building geoportals as an essential part of spatial data infrastructures (GDI). Examples of established portals are e.g. the Geoportal-Bund in Germany or the geoportal of the Austrian Länder geoland.at. Even though some GI companies today offer "GDI frameworks", "toolkits" or "suites", individually suitable software solutions are not available "off the shelf".

The reason for this is essentially that geoportals are not created "on a greenfield site", but have to be integrated into existing environments, e.g. eGovernment infrastructures, with diverse framework conditions. Furthermore, corresponding software solutions are not in mass use, but are rather (further) developed on a project-specific basis. The operator of a geoportal to be set up can therefore not blindly rely on receiving stable standard software. Rather, there will be a need to test and thus qualify the software in cooperation with the provider. The costs for this evaluation in the form of tests may well amount to approx. 30% of the total costs of software projects, and in individual cases even more. 1. Against this background, this article explains which software tests are relevant in the context of geoportals and how they can be carried out.

Geoportals

In a narrower sense, a geoportal is understood to be a website that bundles access to distributed (basic) services (map, data and catalogue services).

2

. For this purpose, geoportals provide various clients (especially map viewers), administration tools and, in turn, services. With the latter, it is possible to provide basic services connected to the portal for external applications in processed form and to network portals in this way.

Architecture of a geoportal

Furthermore, the added value for the user of the aforementioned clients essentially results from the fact that the responses of the basic services are aggregated. Especially if, as is common today, the clients are browser-based, the portal must, for example, display maps from different Web Map Services together or perform coordinate transformations that are not offered by the basic services. Furthermore, the portal must be able to aggregate responses from basic services into service chains (e.g., displaying a map to a geographic location).

The test project

Tests and inspections play an essential role during the entire life cycle of software applications. Already during development, the applications are subjected to unit, component and integration tests. Later, systemand acceptance tests are carried out to check the implemented requirements and specifications, and during the use of the software the quality is ensured by regression and retests in the area of maintenance (updates, patches). Behind all the test variants are a wide variety of methodologies, processes and tools to test different quality criteria of a software, such as the functionality, efficiency or usability of the application.

Established norms and standards, sets of rules and processes help here to carry out test projects in a structured and methodical manner and to ensure the quality of the software. The International Software Testing Qualifications Board (ISTQB), which provides testers and test managers with tools, test processes and a common definition of terms through its "Certified Tester" certification series, can serve as a basis for this.

3

.

The approach presented in the following refers to the system and acceptance test level, since these types of tests focus particularly on the technical requirements. Nevertheless, other upstream and downstream test levels are very important for ensuring the quality of a geoportal.

For the test project to run in a structured and efficient manner, it is necessary on the one hand to position the test project within the overall software development and acceptance process, and on the other hand to establish a test process within the test project. For the situation at hand, the test process based on ISTQB is suitable 4. The individual phases of the test project are explained below.

The test process

Planning and control

As is the case for test projects in general, the technical and organizational framework for the test activities must also be created for the test of a web-based geoportal at the beginning of the test project. An essential part of this is the creation of a test concept. The ANSI/IEEE 829 standard offers a comprehensive structure for planning and transparently presenting the test project. 5. This provides all parties involved with a basis on which to build the test project. The following specifications are made in a test concept:

  • Test Objectives: Different test levels have different test objectives, for example, the objective of a integration testing is to detect interface errors. The goal of a system test is to validate the overall implementation against the requirements.
  • Test End Criteria: In order to know when the goal of a test phase has been reached, end criteria must be defined. These can be, for example, different coverage measures, such as "all Prio 1 test cases and min. 90% of Prio 3 test cases performed".
  • Acceptance Criteria: To evaluate the system at the end of the test project, criteria are required that represent the minimum prerequisite for the use of the system.
  • Definition of the test strategy: For each test level or type of test, it must be determined which methodologies and tools are to be used for test case determination or execution.
  • Definition of the framework conditions: Among other things, the requirements on which the test is based must be defined here, i.e. what must be tested against. These can be existing specification documents such as business concepts or standards and norms such as ISO 19139, to which the geoportal must adhere.
  • Identification, structuring and prioritization of the test objects and functions to be tested: A web-based geoportal can be divided into different test objects, e.g. map clients, interfaces, search functions, etc. These must be identified and prioritized with respect to their criticality.
  • Identification of the test data
  • Definition of the test levels and phases: Here you define which test types are performed or which activities the different test phases, such as test case specification, require.
  • Description of the test infrastructure (test environment, test workstations, hardware and software, tools)
  • Definition of error management (error classes, error workflow)
  • Defining the interruption and resumption criteria
  • Identification of risks and dangers
  • Listing of contact persons, responsibilities and resources
  • Identification of necessary training/education for test personnel
  • Scheduling of test activities (availability of testers, services)

In addition to the test concept, a test controlling is set up, which constantly provides the current status from the test operation. Statements can already be made during the test case specification phase as to how many test cases still need to be described. During test execution, controlling provides an overview of the executed and still open test cases, test case coverage and errors found. In addition, the establishment of an error management is necessary to enable a traceable documentation of the errors and to avoid that errors are "lost".

The information from test controlling and defect management can be prepared for interim and status reports. This ensures constant transparency of the test and allows problems to be identified at an early stage.

Possible test phases and criteria

Analysis and design

The next step is for the testers to analyze the requirements documents and derive and specify test cases from them.

The methods defined in the test concept for test case determination and test case minimization are used here. The test cases are documented in a test case management tool. The documentation of the test scenarios and test cases contains at least:

  • Unique ID for the test case
  • Test idea and test objective
  • Test case description and expected result of the test case execution
  • Test data for the test case
  • Prioritization of the test case
  • Reference to the requirement from which this test case was created
  • Date of test case creation and test case author

When analyzing the requirements, a distinction must be made between the various quality criteria to be tested, for which test cases are specified. For a web-based geoportal, some criteria are relevant here that are typical for Internet applications, among others:

  • Functionality
  • Usability
  • Efficiency
  • Security
Functionality

The functionality test primarily answers the question: "Does the developed and provided geoportal offer those functionalities completely and correctly that are defined in the requirements? Particularly in the case of a geoportal, very complex functionalities arise here in addition to any standard functions as test objects, e.g. in connection with coordinate transformations. Some typical test objects for geoportals are listed below as examples:

  • File functions
  • Administration functions
  • Card Clients
  • Coordinate transformation
  • Gazetteer
  • Catalogue service
  • Interfaces

The special features to be observed in these various test objects are described in more detail in the second part of this article.

Usability

The usability test is used to evaluate the usability of the geoportal and can cover the following topics, among others:

  • User groups: Who will use this geoportal? For example, the depth of help or explanation or efficient navigation through the portal depends on who is going to use the system. There will be different requirements here if subject matter experts work with the portal or private users. Whether these requirements are implemented is the task of the usability test.
  • Styleguide conformity: This tests whether the geoportal has been fully developed in accordance with the specified styleguide.
  • Browser compatibility: With which Internet browsers or operating systems must the geoportal be viewable? It may also be necessary to consider that the complex structure of a geoportal may mean that support for essential functions is sufficient.
  • Accessibility: The issue of accessibility, i.e. the usability of the application by all users, regardless of physical and/or technical capabilities, must be carefully examined in the case of a geoportal. Due to the use of map material, complete accessibility is not possible. It must therefore be clarified in advance which requirements or functions are to be implemented barrier-free.
Efficiency

The test of efficiency examines the geoportal for its behavior under load and overload, e.g. with many simultaneous accesses to the portal. Internet applications in particular must be examined closely here due to the mass of potential users. Here, too, it is important to define specifications in the requirements, e.g. how many users are to be expected at the same time or over a period of time and how quickly the geoportal must respond to requests in certain load states. The regeneration of the system after overload is also a possible test aspect here.

It should be noted that these tests are influenced by factors that cannot be influenced, such as the integration of WMS services from other providers.

For the testing of efficiency, especially for Internet applications, a large number of supporting tools are available from the commercial and the open source sector, which are helpful both for load generation and for the evaluation of the data.

Security

The topic of security is extremely important, especially for Internet applications, and is very often in the headlines. The system and especially the data must be protected against unauthorized access and changes. A user may only see the data for which he is authorized. The security aspect is very comprehensive and requires a high level of technical understanding. Problems with the infrastructure (e.g. the firewall, the network or the web or database server) or newly discovered security holes in applications can make the geoportal vulnerable. Security tests are usually performed by specialists who also understand the technical background. In addition, it is very important to repeat security tests at certain intervals, as updates, configuration changes and newly discovered security holes can create new risks.

In addition to the technical aspects mentioned, security must be considered from the perspective of the application. The question here is: Does each user only receive the content via the geoportal that they are authorized to use?

The prerequisite for an appropriate test execution is the classification of the users and their assignment to rights. In the actual tests, it must first be checked whether the user is correctly authenticated. Following authentication, the geoportal assigns the users to their rights (authorization). In the case of Web Map Services, the rights can relate not only to the layers but also, for example, to scale areas, the spatial extent or the query of attribute data (GetFeatureInfo Request), whereas in the case of Web Feature Services they can relate to the feature types and their attributes.

The correct implementation of these access rights must generally be checked on two levels: First, with regard to the description of the portal services. On the interface level, the capabilities of the services must already be filtered according to the user permissions, i.e., only the layers that the user is allowed to see are included in the capabilities of the WMS. On the client side - to stay with the previous example - only the corresponding layers are displayed for selection. This security level corresponds to the concept of so-called client-based security.

The second test level refers to concrete requests to the portal services bypassing the portal clients, i.e. at the interface level. Unauthorized requests to services are to be blocked by the geoportal and answered with an appropriate message.

In preparation for the test execution, the need for test data is also identified in the course of the analysis of the requirements and the test case creation. This test data must be available prior to test execution. For this purpose, it will be necessary to create test data manually or automatically or to modify existing test data, whereby automatic generation is to be given preference. Another possibility for the provision of test data is the deduction of existing system and, if necessary, the anonymization of this data.

The test data is stored for the test cases in a traceable manner to enable the test cases to be repeated.

Realisation and implementation

After the preparation of the test infrastructure and the preparation of the test cases, they are executed by the testers. During the test phase, both the functional tests and the efficiency, usability and security tests are carried out. In the case of a geoportal, it is important to ensure that all required external services are available during the tests.

The following information is logged per test case during execution:

  • Date/time the test was performed
  • Test staff: Who performed the test case?
  • Status of test execution (OK, Not OK, Possibly not feasible)
  • In the event of an error, the error effect: How does the actual result deviate from the expected result? For example, are incorrect map contents or information displayed?

When an error is found, an entry must be created in the error management. In addition to the exact error description and the metadata, such as the version of the geoportal in which the error occurred, the error is also assigned an error class that describes the severity of the error. The error classes are documented in the test concept.

Provided that errors found in the version under test have been corrected, an error retest and a regression test are performed.

Evaluation and report

At the end of the test, the recorded test results are evaluated, checked against the acceptance and end-of-test criteria and finally assessed in a final test report. The result of the test report is a recommendation as to whether the geoportal can go into operation or be accepted.

In the event that such a recommendation cannot be made, the reasons for this must be listed in detail.

Closing

An important activity at the end of the test project is the analysis and critical review of the entire test, in order to incorporate the experiences and findings in the course of the test process improvement and in further test projects.

Finally, the components, drivers, test data, etc. used for the test are archived so that the test can be repeated or retraced if necessary.

Testing services and clients

In this part follows the description of selected tests and test ideas for the functionality of the geoportal clients as well as for services and interfaces.

Test objects

Test of functional requirements

Due to the complexity of a geoportal, the functionality of the services, interfaces and clients is of particular importance. This also requires an intensive examination of the required functionalities and the underlying norms and standards. In the following, this part of a test project will be dealt with in more detail.

Services and interfaces

The architecture of a geoportal described in Part 1 of the article under 1.2 is based on a loose coupling between the basic services and the geoportal on the one hand, and the portal services and external applications on the other. This requires that defined interfaces are supported by the respective components. In the case of geoservices, these interfaces are described by the Open Geospatial Consortium (OGC) as implementation specifications and, if necessary, further specified by profiles. Compliance with these specifications is essential for portal components that serve external communication and therefore plays a prominent role in the tests.

The tool of choice for testing compliance with the OGC specifications is the CITE program (Conformance & Interoperability Test & Evaluation) offered by the OGC, which has since been completely revised. Among other things, tests for various services such as Web Map Services (WMS), Web Feature Services (WFS) and Catalog Services (CSW) are possible here. The relevant information on the procedure and the terms of use can be found on the CITE homepage.

6

. From the perspective of a portal, however, there are some special features that limit the use of CITE tests. First of all, the CITE server must have full access to the services to be tested. This can be problematic in development environments or in secured networks. Furthermore, the CITE scenario requires the inclusion of test data provided by the OGC in the services to be tested. However, portal services usually do not access their own data, but cascade to external services. In this respect, most CITE tests are not applicable to portal services. Client component tests are not covered by the CITE program. Furthermore, tests on profiles as well as tests on the fulfilment of functional requirements, which are specifically tailored to the conditions in the respective geoportal, cannot be carried out with CITE. In this respect, own test ideas must be defined, where possible based on CITE.

Map service (WMS)

The map service is the most frequently used service of a geoportal and therefore of central importance.

The tests here are based on the three WMS interfaces GetCapabilities, GetMap and GetFeatureInfo. With a few exceptions, all interface tests are to be performed by calling the interface directly, e.g. by entering it as a browser URL, in order to exclude possible errors in the WMS clients. The response of the service is then compared with the expected result. The concrete structure of the corresponding requests will not be discussed here.

7

.

Regarding the GetCapabilities interface, for example, the following test ideas are useful:

  • Validity of Capabilities.xml according to WMS version
  • correct behaviour in the context of version negotiation (answering the request with the requested version, otherwise with the highest implemented version number)
  • Correctness of all specified OnlineResource URLs
  • Completeness of the service metadata (This test case is of secondary importance for the actual functionality of the service. In interoperable environments, however, this metadata is evaluated by catalog services, for example, and should therefore be listed completely in the capabilities of the WMS).

The GetMap interface is the central interface for map services. The tests for a correct functioning are very extensive. For this reason, only a few essential test ideas are discussed here:

  • Robustness of the service in case of failure of connected basic services (this case should be explicitly brought about by switching off one of the basic services).
  • Presence of the layers specified in the capabilities
  • Support of the image formats and coordinate reference systems (SRS) specified in the capabilities.
  • correct interpretation of the parameters for transparency and background color
  • Provision of a map in the width/height ratio of the image requested by the client (independent of the width/height ratio of the bounding box)
  • Test of the coordinate transformation of the WMS (see 2.1.1.5)

As a rule, scale hints for individual or all layers are specified in the capabilities for security, performance and/or marketing reasons. In this case, tests should follow to ensure compliance. Some manual computational effort is required to manually generate GetMap requests with correct content. However, the calculated bounding boxes can be reused in other test cases.

A further test complex relates to the representation of the layers. Here, the following test ideas, among others, are to be defined:

  • Can each layer be displayed according to the layer styles specified in the capabilities?
  • Is the assignment between layer and style correct according to the order in the GetMap request?
  • Is it possible to request the layers in the default style via an empty STYLES parameter (STYLES=) or null values in the style list (e.g. STYLES=,,)? Is the combination of the latter notations with named styles possible?

If SLD-capable services are to be integrated in the geoportal, additional tests refer to whether the corresponding SLD parameters (e.g. SLD=) are "passed through" to these services and the result map is rendered in the desired style.

When testing the GetFeatureInfo interface, it should first be checked whether the feature data query is possible for each layer that was marked with the attribute queryable="1" in the capabilities of the service. Analogous to the GetMap interface, it should still be possible to generate all specified output formats for information representation. However, if the corresponding parameter (INFO_FORMAT) is omitted, the output must still be in one of the formats specified in the capabilities.

In addition, each interface should be tested to see if it works correctly with both mandatory and optional parameters, and if it returns a valid result without vendor-specific parameters.

Data service

Data services in geoportals have the task of answering queries for geographical objects such as places, addresses or regions (Gazetteer Service) and/or providing raster or vector data (Web Coverage Service or Web Feature Service). There is no OGC standard for gazetteer services yet; the corresponding paper currently has the status of a best practice document.

8

. A Gazetteer Service is treated as an application profile of a WFS. If the gazetteer service of a geoportal is to use standardized interfaces, only the use of a WFS can be considered. For the use and further processing of the results, in addition to the interface conformity of the service, the question of whether correct results are delivered is of particular interest. With this in mind, the following test ideas were selected, whereby only the currently most frequently implemented version 1.0.0 of a Basic WFS is referred to here.

The following questions, among others, arise in connection with the GetCapabilities interface of a WFS:

  • Is the Capabilities Response valid and does it match the specified version number?
  • Are feature types output correctly and is a valid SRS assigned to each?
  • Is at least the GML2 format specified as the ResultFormat?

With regard to the DescribeFeatureType interface, it must first be checked whether the server response provides a valid GML schema and whether all FeatureTypes of the WFS are described even without specifying the TYPENAME parameter.

From a content point of view, when testing the DescribeFeatureType interface, particular attention should be paid to ensuring that only those attributes of the features are described which are also to be "made public" via the service.

In relation to the GetFeature interface, it must then be tested accordingly whether only the data for these attributes is actually output. For this purpose, the parameter PROPERTYNAME must be provided with the value * in the GetFeature request and completely omitted in a second test. Furthermore, at least the following test ideas should be used:

  • Validity of the returned GML document against the DescribeFeatureType XSchema including the imported GML schemas.
  • Support of the filter encoding methods specified in the capabilities
  • Correctness of query results when using filter encoding (e.g. comparison with SQL queries)

The last test is relatively time-consuming, since filter encoding queries can be very complex on the one hand, and on the other hand, meaningful queries must be created using the existing data, the results of which must then be checked. One should be aware that these tests in particular only represent random samples.

In addition, it should be checked for all operations of a WFS that both the HTTP request methods GET and POST are supported. While queries using the GET method can be carried out via the input as a browser URL, this is not possible with POST. Here, for example, a specially developed website or application with an input form that is sent to the server via the POST method can help (in the case of the website, this requires storage rights on a web server).

Coordinate Transformation Service

Coordinate transformations are required at various points in geoportals. Here, the focus is initially on server-side transformations; client-side transformations are dealt with under 2.1.3.1.

The corresponding functionality is usually not provided externally as an OGC Web Service, but is only used internally. In this respect, the necessary tests are aimed at the results of the transformation and not at interfaces.

Most important are coordinate transformations in connection with the transformation of map images in WMS requests. Transformations are to be implemented by portal components if SRS are requested on the client side that are not supported by the basic services.

The transformation routine of the portal WMS can be tested using a separate reference data set. As a test dataset, it is advisable to use, for example, a rectangle that is approximately the size of the geographical area for which the transformation is to be tested.

This rectangle is stored in different layers in the SRS of interest, whereby its (target) coordinates are calculated manually in each case. The GetMap request sent in the browser requests maps in the various SRS, with the layer that is not to be transformed serving as the reference. Alternatively, and faster to implement, the bounding box can also be used as a reference.

Verification by means of reference geometries
Verification by means of bounding box

If the geoportal offers functionalities for geo-searching (e.g. places, addresses, etc.) as well as for visualising the search results, a coordinate transformation is required if the SRS of the map does not match that of the search results. If the search runs via a WFS, the coordinate transformation is performed either by a corresponding coordinate transformation service (mandatory up to WFS version 1.0.0) or by the WFS itself (from version 1.1.0, whereby a transformation service can also be addressed internally here). Here, too, the coordinate transformation service is only used within the geoportal for the conversion of individual (GML) features in the requested SRS and is not offered as a service to the outside. In this case, it is not the interfaces of the service that need to be tested, but only the correct result of the transformation. This is naturally given if map and visualized GML features overlap correctly.

When interpreting the test results, it should be noted that coordinate transformations have different geometric accuracies. In order to be able to identify errors during the transformation it is therefore necessary to know the accuracy potential of the respective transformation method and parameters: For transformations between Gauss-Krüger strips (e.g. EPSG codes 31466 to 31469) the ellipsoid is not changed and strict formulas are applied. Here, the accuracy is also correspondingly high. In case of transformations, however, where a datum transition is required, e.g. from Gauss-Krüger coordinates on the Bessel ellipsoid to UTM coordinates on the GRS80 ellipsoid (EPSG codes for Germany: 25832 and 25833), the conversion is not performed strictly, but via transformation parameters. Thereby there are a number of different parameter sets for Germany, which differ by the accuracy, related to a (geographical) area of use. Accordingly, coordinate differences of a few meters can occur if nominal and actual coordinates were calculated via different parameter sets.

Administration functions

The administration options of the geoportal include, among other things, the configuration of access rights to the various data, services and functions, but also the integration and arrangement of a wide variety of services, layers and specialist data in the portal clients.

Clients

While the functionality of geo-services is essentially defined by standardization, the functionality of clients can vary greatly between the different geoportals due to different requirements and implementations. For this reason, only selected test objects with corresponding test ideas can be discussed here.

Card Clients

Map clients can offer a different wealth of functionality depending on how they are designed and how they are used. This can also depend on the technology used, so a Java or AJAX based client will offer more possibilities than an HTML client that may not even use Javascript.

The following typical functions of card clients could be used as test ideas:

  • Navigation via maps: Sections of the maps can be zoomed in, zoomed out or moved with certain factors.
  • Calculations: Area and length calculations, but also the representation of coordinates to specific points.
  • Compilations: The addition, removal, and reordering of different layers or services.
  • File functions: Saving various settings, such as layer combinations, map sections and sizes at the portal or locally. These settings can be reloaded at a later time in order to continue working. Also the saving of map sections and subject information.
  • Print functions: The print functions of Internet browsers do not do justice to many situations, print functions of map clients can therefore often include different print sizes, resolutions and information or already offer the print results as PDF files.

Coordinate transformations (cf. 2.1.1.5) are also required for client components:

  • Transformation of image coordinates into world coordinates for each map navigation to generate the bounding box of the map request
  • Transformation of the bounding box in the event of user-side changes to the SRS
  • Display of world coordinates

In the simplest case, the transformation of the coordinates of the bounding box is checked by means of the map client's coordinate display. If this is not implemented, it may be possible to use network protocol analysis tools to view the incoming and outgoing data traffic at the client via the HTTP protocol and thus the transformed coordinates.

The coordinate display of the client can be checked by a simple nominal/actual comparison of control points.

Clients for address and location search

By means of these clients, requests for geographical regions, addresses or locations are forwarded to decentralized gazetteer services and the results found are usually visualized directly in the map client of the geoportal. The clients are therefore expected to formulate the corresponding requests correctly. In practice, this is checked indirectly by comparing the results of requests via the client with those of HTTP requests at the service.

This should include testing whether different ways of entering the search terms lead to correct answers. These could be, for example:

  • exact search by quotation marks (e.g. "Zittauer Gebirge")
  • Consideration of placeholders (? or *)
  • (optional) Case sensitivity
  • Search with umlauts or their substitutions (e.g. ä -> ae, ß -> ss)
  • logical combination of search terms with AND, OR, NOT
  • Absence of address suffixes such as street, road, shore
  • fuzzy search with incorrect spelling etc.

Further test scenarios then relate to the presentation of the results:

  • correct rendering of the search results (e.g. position in the map correctly displayed),
  • Consideration of the criteria set up with regard to usability (e.g. sorted hit list in the case of several hits with selection option by the user, "speaking" messages in the case of incorrect input or empty result set, limitation of the number of hits, alternatively request to refine the search criteria).
Clients for searching data and services

Catalog clients for searching data and services usually query multiple ISO 19115/19119 based metadata catalogs. The prerequisite is that the client supports searching via the application profiles implemented in the connected catalogue services, e.g. the DE profile of the ISO19115/ISO19119 application profile for OGC Web Catalogue Services (CSW-2.0)

9

.

In analogy to the address and location search, the hit list of a search query must also be checked for correctness. This can be done by submitting identical queries via the metadata search client of the geoportal on the one hand and directly to the externally connected metadata catalogues on the other, e.g. via their clients or (better) as SOAP requests. Both responses are then to be compared. Different input variants (see 2.1.3.2) must also lead to correct results here.

A further test complex relates to the presentation of the search results in the client. Here, test ideas are to be designed, which test these with regard to

  • correctness of the content of the results presented (comparison with the direct queries to the distributed metadata catalogues),
  • Completeness of the displayed metadata elements (depending on the agreed profile of the result set: BRIEF, SUMMARY or FULL) and
  • Usability (e.g. sensible sorting of the hit list, linking to service providers or the possibility of loading found services into the geoportal)

Check.

Conclusion

The rapid spread of geoportals and their use even by GIS laymen, applications in critical areas such as homeland security or disaster control, and not least the special features of the underlying service-oriented architecture are some of the aspects that give rise to special quality requirements for the corresponding software solutions. The software tests necessary to ensure these quality requirements were the subject of this two-part paper. In particular, it was shown how general IT testing and GI application know-how intertwine in the specification and execution of the tests and thus contribute to the success of the project.

In the future, especially in the area of test automation, further possibilities will arise here to make the necessary tests even more efficient.

  1. Sneed, H. / Baumgartner, M. / Seidl, R.: Der system testing - Anforderungsbasiertes Testen von Software-Systemen, Carl Hanser Verlag München Wien, 2006
  2. Open Geospatial Consortium Inc.: Geospatial Portal Reference Architecture, 2004
  3. International Software Testing Qualifications Board.: ISTQB, 2007
  4. Spillner, A. / Linz, T.: Basiswissen Softwaretest, dpunkt.verlag GmbH, 2005
  5. IEEE: ANSI/IEEE Standard 829-1998 - IEEE Standard for Software Test Documentation, IEEE Computer Society, 1998
  6. Open Geospatial Consortium Inc.: Compliance & Interoperability Testing & Evaluation Initiative, 2007
  7. Open Geospatial Consortium Inc.: Web Map Service Implementation Specification 1.1.1, 2002
  8. Open Geospatial Consortium Inc.: Gazetteer Service - Application Profile of the Web Feature Service Implementation Specification
  9. GDI-DE: DE-Profile of the ISO19115/ISO19119 Application Profile for OGC Web Catalogue Services (CSW-2.0), Geoportal Bund, 2005