Introduction

The simplest functional testing technique is which is known as exploratory testing (exploratory testing) that is to find fails on purpose and by a more or less structured way but without a predefined script.

The simple use of the application could be also considered as an exploratory testing, since it is not strange to find fails althought they are not looked for on purpose. Actually, when we use the application we cover lots of test cases which they couldn't be covered by systematic testing.

It should be emphasized that testing is not just the fails search, although perhaps it is the most important part. To repair fails efinciently, it is essential that testers follow some steps: failure reproduction, to investigate the specific causes, to check if a related issue already exists and, finally, if it was necessary, to open a new issue. This document compiles some best practices to take into account for each action.

Failure research

Here there are some advices to do exploratory testing:

• Try to test every option of each tool or functionallity, even to cancel.
• Test the application robustness in illogical test cases (e.g. introduce a letter in a text box which expects a numeric data). At this kind of testing a lot of fails are often discovered since frequently developers are focused on logical cases and forget the illogical ones.
• In general, the attitude adopted by the tester should be to try to "break" the application, finding its fissures and its limits.
• Identify variables and their values, which, a priori, would cause differents behaviors from the application. This optimizes tests since it minimizes the test cases number keeping the coverage. For instance, gvSIG uses the same driver for every raster file format. For a large amount of tests, to try with more than one raster file format would be redundant since it is not expected that the behavior would be different according to the format. So the raster file format in this case would not be a variable taken into account. In the case commented before about the text box, the variable would be the character type (numeric / alphanumeric). Besides, we could differentiate between integer and double fornumeric values. These values compile a priori every case where we could expect different behaviors.

Failure reproduction

To repair a detected failure -detected casualy or by exploratory testing-, firstly we have to be able to repeat conditions which produce it. Then, the first thing we'll do when we find an error will be to reproduce it, i.e. reproduce step by step conditions at the moment when it happened. In the first place we would try with last actions before to find the failure and if it is not possible to reproduce it, we would go back to previous actions. At the moment we are able to reproduce the failure twice consecutively doing exactly same steps, we can conclude the failure is reproducible.

Investigating the failure specific causes

To be able to reproduce the failure is essential but not enough. It is possible to identify the steps list which lead to this failure but it is probably that some steps do not really have an influence over the problem. This information is not only irrelevant but could be counterproductive for repairing the error since it makes follow false trails.

Frequently, the real cause of a failure is not related with the first idea at the moment it was detected. Then, always it is necessary to carry out a minimum invetigation about real causes. Look an example:

Let's say we have a zoom error in a view with several kinds of layers: raster, vector, local and remote. If we had to write the error title, we could write something like "Zoom error". Suppose we start to dismiss variables and discover that the error only have to do with one of them (the vector one), we could wonder if this error appears with every vector layer or just with the loaded one. We try with other vector layer and it does not happen. Then, we wonder about special layer characteristics. It has a configurated labeling. We disable the labeling and discover the error does not appear. Also we can dismiss if it happens just zooming or refreshing the view too. We discover the latest one. Moreover, we test different kinds of vector layer and we observe that the problem just appears with WFS layers. What a priori seemed to be a zoom error, finally, is a WFS labeling problem.

It is about to identify variables and their several values which could change the behavior. Some variables we could manipulate to define the error are:

• Kind of data source: raster/vector, local/remote, file format, layer, server...
• Reference system.
• Units of measurement.
• Kind of legend.
• Etc.

It is advisable to point out that, at the moment of identify these variables, it is important own experience using the application and testing.

Checking if the issue has been registered before

Once the failure cause is identified and before to open the corresponding issue, it is advisable to check if it has been detected and reported before, i.e., if there already exists an opened issue related with this failure. It is important to avoid the issue duplicity.

In order to that, we will access to the bug tracker and we will do some research by the filter tool or by the search text box (upper right corner).

If an issue related with the failure already exists, we will try to add some relevant information. Otherwise we will open a new issue.

Opening a new issue

Once we checked that there is no issue related with the failure, we will open a new one from the tracker (Register required. Get an user account ).

Before that it is important to have all necessary information compiled:

• Version and gvSIG build numbers [1] (look up menu “About...” of gvSIG).
• Extension version number [1] [2] (look up menu “About...” of gvSIG).
• Operative system [1]
• Failure log file [1] [3]. ( Where we can find gvSIG log file ).
• Data file [3].
• Screenshots [3].
• Name of test case and test plan. In case that the failure has been detected executing a test plan, it is recommended to indicate both in the failure description.

Likewise the application behavior after the failure should be taken into account to define how important this failure is.

Basically to identify if we can continue using the application normally or not, and if there is some data or configuration loss, in which case the data should be contributed to the issue.

Once all information is compiled, we will fill in the issue (look up Help filling in issues).

Finally, it will be taken into account that the recomended language is English.