Skip to main content

Smallworld GIS testing – best practices


Quality of IT solutions depends on the quality of tests that they have passed – it is an obvious statement. As tests play a significant role in our software development and delivery process, we decided to share a few good testing practices derived from our activities related to GE Smallworld GIS solutions. In addition to that, we show how the testing process looks like in Globema.

Let’s start with testing the applications based on GE Smallworld GIS:

  • remember to copy the development environment with the database and create a separate testing environment from it
  • don’t test on the server where the environment is installed, but run the application on workstations off a mapped share
  • don’t forget about expanding images to ensure that all patches are loaded
  • run the application with the emacs console. With this console, you can read the basic information about the error encountered and copy its contents
  • prepare different groups with users and configure the access levels accordingly
  • prepare the appropriate test package on which you will perform some tests, for example, vector and raster files in various formats and in different coordinate systems, documents attached to objects, etc.
  • test alternatives in the relevant banks: ACE, STYLE, GIS, etc.
  • upload patches with fixes to a given location, for example, DH.GIS….\SW_APP \EC…….\source\image_patches, and enter patch numbers into the patch list continuously and in a chronological order
  • the appearance of the editors in the application may vary depending on how the XML files responsible for their construction are configured. Please note that at the directory structure level …\SW_APP there are 2–3 different configurations that override hierarchically.

It’s a good practice writing tests for:

  • different Smallworld environments – for example, single screen, dual screen, etc.
  • for different users, with different levels of access to: tables, parameters and alternatives
  • regression tests – errors found earlier and corrected should be re-tested together with the functional area around the corrected error
  • various types of tests: performance, scalability, security, usability, maintenance and functional procedures

Testing at Globema – how does it work?

First of all, it’s based on an iterative approach using agile methodologies, such as Scrum. The iterative model of software development allows for the cooperation of programmers, testers, analysts and clients at an early stage.

This approach allows on:

  • validation of the prepared requirements with the client’s needs
  • flexible response to possible changes in requirements. Early detection of inconsistencies between requirements, design, and implementation results
  • detection and neutralization of the largest threats during the initial merging operations – integration testing in small
  • minimizing the number of patches ­– each iteration ends with merging
  • an objective assessment of the project status and the quality of the service
  • the development process itself is improved during the project – retrospection at the end of each iteration also includes what can be improved in the next one.

Software defects are not only the result of coding errors – a large part of them is the result of errors made while listing the requirements. Therefore, we start the tests at the analysis stage:

  • we carry out validation of requirements (incl. requirements have to be feasible, unambiguous, measurable, unitary, compatible, understandable)
  • we give priorities to the requirements
  • we define design and product risks
  • knowing the purpose of the project and the requirements, we prepare the Test Strategy.

In order to ensure the high quality of the software, mainly ISTQB, ITIL and REQB certified employees are involved in the testing process.

Last but not least – testing is an absolutely necessary element in the development and delivery of software. There are many reasons, including: