I had to responed to this subject. Ia have worked with GIS Systems for the last five years up to now I have been working with GIS Systems for the marine and off shore oil sector but next monday i am moving to Ordnance Survey the UKs leading mapping agency. Agree with Jake that processes, methods, and practices apply to testing regardless of the technology which is totally true regarding to GIS except automation is slightly more difficult with GIS Systems but you can still automate GIS applications. Heavyd I need to have more information on what type of GIS application you are testing and what type testing you are doing. Is thne GIS application you are testing purely a GIS system or does it interact with GPS systems and satellite systems? Is the testing purely manual? Is your GIS System standalone , Client Server or Web Based? Is the testing you do purely fsystem tseting or do any performance and load testing?
Haven't done much GIS testing, but I have been involved in development of land surveying, mapping and modelling systems over the last 22 years. Biggest headache that I had was implementing automated testing of the vector graphics. If you do a search for graphics, CAD, and/or GIS in the automation forum you will find discussion on this. One of the core problems that I had was that I wanted to develop certain tests by manipulating geographic objects with the mouse. Generic recording tools store these coordinates as windows relative mouse coordinates, whereas you ideally want to deal with geographic coordinates in your script. While I am not an advocate of record playback techniques, hand scripting the manipulation of a geographic object whose coordinates may not be easily accessible is a real pain. My solution was to have the AUT log all mouse clicks in windows and geographic coordinates for merging back into my test script. If you attempt to automate using Windows coordinates, you will find that your script can be broken by changing display resolution, or changing one of many minor Windows display configuration settings.
As Chris alludes to above, if you are not doing performance testing, you should probably consider it. The reason for this is that many poorly coded 2d routines can have performance degradation in the order n-squared or higher, and 3d routines similarly can have order n-cubed or higher. This can lead to systems becoming unusably slow very easily, and is something you can easily miss while testing.