Room and Pillar approach for software testing

A journey underground
In the beginning of this month I went with a group of colleagues to "the caves" of Maastricht in The Netherlands. During this trip in the dungeons of the earth I learned that this was a result of mining and not a natural phenomenon. What I found impressive was the way they cut the stones out of the earth. To me it looks a bit like "negative building", you built something by taking away sources.

They start to work on the top and dig their way down below. Only it was not just start digging, they first search for the flint. If they found it they knew what level the ceiling would be. This was an approach they used for centuries. In that time you were owner of the ground below your property. This means that boundaries were set based on the size of property above ground.

As there were more people who were mining in that area, the chance to meet your neighbor underground was accepted. To prevent that others are digging in your area marks were set on the walls. As the mine extend the risk for collapsing increased. To avoid this they came up with a method to dig enough stone away and still maintain the supporting structure. This was done by leaving pieces of stone to act as pillars. The result was that you have now a area with pillars and rooms you can safely walk through from one side to another side.

What is Room and Pillar mining?
According to Wikipedia: Room and pillar: "Room and pillar is a mining system in which the mined material is extracted across a horizontal plane while leaving "pillars" of untouched material to support the overburden leaving open areas or "rooms" underground. It is usually used for relatively flat-lying deposits, such as those that follow a particular stratum"



William A Hustrulid and Richard L. Bullock explained the method as: "If one pillar fails and surrounding pillars are unable to support the area previously supported by the failed pillar they may in turn fail. This could lead to the collapse of the whole mine. To prevent this the mine is divided up into areas or panels" Note:*1

Mining and software testing
Somehow I see some similarity to this kind of mining and software testing. We also are trying to dig our way through the system. In my opinion we are also performing some negative building. Although we are not building the software ourselves, we try to find errors which will lead to changes in building. Also we are starting from the surface and going downwards in the system until we are called to stop. If we look at the explanation of Hustrulid and Bullock we also might phase a collapse of the system if we tested to deep or wrong. For example we perform wrong actions which leads to stopping is for further testing of that test case or data might get corrupted.

Pillar and Rooms in Organizations
Perhaps this is a bit far-fetched; processes in organizations can also be seen as pillars and rooms. If you take for granted that organizations are performing activities and those activities are assigned to processes you can create a similar map like shown in the figure below.



In level 1 you can define the departments. In level 2 the main processes and in Level 3 their sub-processes. Each block in a level is a room where activities are performed and the information is handed over to another room. To transfer these information agreements on communication and format must be defined. These can be seen as the pillars for the organization.

Mapping your test cases
To find your way through the mines you also need a map and a guide. To find you way to the system and check if the system supporting the business processes you can use a similar map of processes.

This map can be used to make the path of test scenarios visible. Those paths can be used to present certain coverage of the system towards the business processes. Initially you can show that based on the selected test cases you cover every business process at least once. Another benefit is the creation of transparency that the system is able to process data to support the processes.
Secondary use of this map is to can be as a storyboard. Let the business explain what they are doing in their processes, what their understanding is about the impact of their changes in data for next processes and also prioritize their activities. These priorities can be used to add depth in the test cases.



Test coordinator as guide
Even if you have a map of the mine, it will always be hard to find your way through the system. To speed up you journey through those mines to make sure you see the important things and find your way back to the exit it is recommended to get a guide who leads you. To lead you through the system you can assign this task to the test coordinator. He uses the map to lead you through the system and based on this map he explains in terms (processes and activities) you know what it mentionable to pay attention to. As for a guide in the mines the gas lamp, an additional flash light and his experience of the environment helps to make the journey pleasurable. The test coordinator should bring in his experience of the system, the test process and other additional tools to make it worthwhile.

Creating test depth in the room
I already mentioned to define test cases based on using every process at least once. This can be done using test cases for proving the system is supporting level 2 processes. I suggest going at least through every Level 3 processes.

As one of the main borders are activities and every process can consist out of more then one activity you can use the prioritization to decide if a certain path should be performed multiple times. Or combine activities as you are staying in a room for a longer period. As example a process can exist on: creating, maintaining and deleting data.

You could derive here three similar paths for it. You also can use it in one path. If you are using it in a same flow you have to be sure that the next process is not of the same priority and also the mutation of data has a minor effect on that process.

Mining the Business Process Chain Testing
In my opinion the approach of pillars and rooms is very useful to define a set of test cases to support Business Process Chain Testing (BPCT). You approach the system from a business point of view and measure if the system is supporting the organizational processes. Based on importance and risks you can define the depth of test cases. Also using a structure as pillars and rooms you are able to tell the business what kind of test approach you have and how you make sure that important things are done. You also are able based on the activities which have to be performed which resource you need from the business to perform the test cases.

Note: *1 William A Hustrulid and Richard L. Bullock (2001). Underground Mining Methods: Engineering Fundamentals and International Case Studies. Society of Mining Engineers, p 493-494. ISBN 0873351932.