This weekend Altom participated for the second time in LetsDoItRomania
! The program is part of http://www.letsdoitworld.org/
, started by the Estonians in 2008, that has the target to clean the country by involving a big number of people. This year we didn’t have the time to get involved in the organization of the event, but we managed to gather a team of 5 people: Ionela, Levi, Ramona, Oana and myself :D.
We got the garbage bags and the plastic gloves from the organizers, we bought two pairs of industrial work gloves and we borrowed a fork and shovel (lessons learned from last year), we chose two garbage sites near Valisoara, a remote village near Transilvania Highway, and on Saturday morning, 24th of September, we left Cluj to clean them :D.
This whole experience reminded me a lot of the software projects I’m involved in as a tester. I think this was a great example of how someone can learn about software testing by doing something not related to work, and I will try to explain why.
On Friday we had decided to meet the next day at 9:00 AM and leave for the selected sites, but on Saturday morning when we looked for the sites details (pictures, GPS coordinates, description) the application was not showing any of the needed information. We found out that the organizers had set up a local call center, we called them (we had to wait until we were able to get someone on the other line) and someone was able to give us the GPS coordinates for the selected locations.
All this hassle delayed our departure with around 20 minutes. One thing we could have done to minimize the risk of this happening was to look for the information on Friday evening, but we were too optimistic and left this important task for the last moment :).
Has that never happened to you when starting a new testing project: realizing that you didn’t have important information, and in order to get it you had to call someone on the client side/development team which delayed the start of your work?
Our village doesn’t have garbage
Once we found the information we needed, we entered the GPS coordinates and we left for the 1st location. We arrived in the village, and even if we had the coordinates, we stopped to talk to an old man and get some inside information :).
I first asked him if he knew about areas used by the village people to dump the garbage, and his answer was that the village was clean, as they had a garbage collection system and that took care of the problem. I continued by asking: “well, but before this system was put in place, where did you use to dump the garbage?”, and his answer was: “well, but that was a long time ago…”.
This short discussion reminded me of lots of developer’s / engineering manager’s answers I got while testing: “our code doesn’t have bugs, as we use this system/process (please read garbage collector, unit tests, code review) that makes sure everything is taken care of.”
I told the old man that it had been reported that there were areas in the village where garbage was dumped, and his first reaction was: “Who said that? Was it someone from the village?”. I said “No, not someone from the village”, then he replied “Well, if they’re not from the village, then they don’t know”
Working as a consultant I often noticed this attitude: “if you’re not from the organization, how dare you say we have a problem?”
Changes you don’t know about
We left the old man, and continued our way to the first garbage site. We stopped where pointed by the GPS coordinates, but unfortunately there was no dump yard there. Instead, we found some men who were trying to build something. I got off the car and went to talk to them. One guy came towards me and told me that he had bought the area one year ago, and that he had cleaned most of the garbage.
It happened to me while testing to find out that parts of the application or functionalities had been removed, but the documentation had not been updated in the meanwhile. This was the case with this location too: the garbage site had been reported last year, but no one cared /had the time to check and update the details of the site.
We phoned the call center again, and asked them to assign us another site somewhere in the neighborhood. Once we got the new details, we headed to the new site which was at the other end of the village.
Understanding the impact
The site was on the water stream, which is quite a common location. For some reason people think that it’s OK to throw their garbage in the stream / river, as the water takes it away, but they don’t think that the people up the stream can, and will, do the same thing or that their garbage will harm the people down the stream.
The way we perceive the impact of our actions always amazes me. As the villagers don’t understand that the animals (domestic or wild) will drink from that water and that they will later eat the meat or they’ll drink the milk and get sick.
It often happens that we don’t understand or minimize the risks introduced by the changes done in the software application we develop.
Estimating the amount of garbage
The procedure when mapping the gar
bage sites is the following: someone identifies the location, gets the GPS coordinates, takes some pictures and enters some details describing the type of garbage that is found there and estimating the amount of garbage bags needed to clean up the location. This was the third time I took part in a cleaning action (last year I participated both in the pilot event and in the national event), and every time the estimates were way off. For this year’s location, the estimates were 25 garbage bags. We collected 44, and we could have had more if we had continued until sunset.
Another thing I noticed was that the garbage bags were not identical: some had more garbage than others, they contained different things (plastic bottles, clothes, rubber, glass bottles…), some were heavier that others.
This reminded me of a project I worked on that used some algorithm to estimate the number of bugs that should be found in the application, and afterwards reviewed testing based on bug numbers…
After approximately four hours of intense fight with the garbage and nettles, we decided to stop. We had to call the organizers and tell them the exact location where we had left the garbage bags so pickup trucks could come to take them.
One of the questions they asked me was the coverage percentage for that site. I told them that the estimates were 25 bags and we collected 44, so what kind of percentage did they want?
One thing I want to specify about garbage dumps is that they pile up between plants and the earth brought by the water. It’s like thinking of different layers of an application. So if one continues to dig, there’s a big chance that s/he’ll find more garbage. This is why I thought that providing a percentage was kind of useless. In order to know the percentage, we needed to know the total amount of the garbage that was located on the site, something we couldn’t know for sure.
The girl on the phone insisted I give her a number, and I said 70%. While I’m writing this I question my answer and wonder if that was the right thing to do… If a client asks me for something, and I explain them that this number is useless but they still ask for it, is it OK to give them my best guestimate? I’ve offered them my advice, but they are the ones paying, after all… For an interesting view of this issue please see the first 5 minutes of this TEDTalk – the Japanese tea story: http://goo.gl/I64c
One of the things that I like most about being a tester is that I often find similarities between my work and day-to-day events, which makes learning more interesting and fun :).