I saw an amplified post from Jerry Weinberg on maps, here, and the ongoing Agile Testing Days in Berlin. I had a weekend in Berlin a couple of weeks ago - and I made a note in my notebook at the time.
After one day/night there I made a note "Map chaos: Scale and position on many Berlin maps do not correspond". Yes, I also had a testing perspective in mind.
I had looked at 4 different maps (from different sources) and none seemed to tie in or they all gave me problems of different kinds.
- On the plane I had been reading an flight magazine with a feature on Berlin nightlife - unfortunately their map didn't correspond to any of the other Berlin maps I had! I guess the map maker of that one was still under the influence when making the map - so yes, that was useless.
- After landing I decided to "go native" and travel as much local transport as possible. However, interpretting the map for the link between the airport and the u/s-bahn system was not straightforward (to my non-Berlin-trained eyes!) I eventually got the message by the time I was leaving!
- In my Time Out guide to Berlin all there detailed maps of the city centre (I was staying in Mitte - the centre) didn't have the street that my hotel was on - even though it was just around the corner from a main U-bahn station. This made even getting to my hotel tricky - as the last bit I did on foot. I got there by deducing which of the streets it must be based on the information I had of surrounding streets. Yes, I would've asked a passer-by but there weren't any...
- Then there was the map I got from the hotel reception - at least that one had the street of the hotel on it! This was the most heavilly used map. But even this one had problems - when trying to get to a local landmark we asked a taxi driver (you'd think they'd have a good grasp on the sites) and he was non-plussed. When we showed him the map and pointed to the place with the name, he called it something else as though it was obvious!
So what's the testing tie-in?
Yes, this works on many levels. Perspective (or context): You understand the map quickly if 1) you understand how the map maker made it, 2) you have a link to a common understanding of the mapping principles.
Take contours as an example - if you don't know anything about contour lines then they're not going to mean anything on a map - and you could end up trying to climb some big hills unintentionally!
Underground/subway maps are typically drawn from the perspective of having a neat/even distribution of the lines & stations to be able to show that in a "nice/tidy" way. They're not meant for guides to "how to get to the station if you're walking above ground".
So, what were the bad assumptions with each of my maps?
Map #1: It turned out that this map was not to scale and only vaguely correct where the rivers junctions and districts were concerned - it was very scant on detail. Lesson: If the detail isn't there (and you need it to make sense of the situation) be suspicious - start asking questions.
Map #2: No real guide how to use for the bus-ubahn connections - for the un-initiated. I don't mind "using to learn" but it would be good if the map told that's how I'd learn about it... Lesson: Sometimes you just have to suck it and see!
Map #3: Although the book was a 2009 edition my hotel straight was on a line with the "wall" - meaning that the street wasn't useable on the first maps that they'd based their guide on. Lesson: Use your own "fuzzy belief" or "fuzzy logic" - use the information you can see and confirm - where there are gaps use the surrounding information to help interpolate/deduce.
Map #4: This seemed to be the most accurate and useful map but it still was understood by some of the locals. They obviously had their own map (whether real or mental). Lesson: Synch'ing your perspective to someone elses is important (and probably underrated in communication.)
What more did I learn from the exercise?
These apply everywhere, but including our daily testing lives:
- Don't take anything for granted - especially when 4 different sources are giving 4 different versions of information. Don't take for granted that whoever you communicate with have a shared perspective - check that you're both "in synch".
- Always try and have an assessment of your own meaning of the situation. Take the data you're getting and make your own story - how you'd re-tell the story of all the information you've just taken in.
- Lack of data in a situation where you need it to make sense of the situation? Whether this is map reading or interpretting a customer requirement - it's time to start asking questions!
I'm sure there are more map-making & testing analogies out there. Anyone?
Hi Simon,
ReplyDeleteCool post. I like the lessons learned section. And they are valuable lessons which take in to account knowledge, context and understanding of the topic. Things we see often missing from the testing that takes place.
One map and testing analogy that is out in the wild is the fact that you can buy different maps for different audiences and purposes. So always double check your audiences needs. Some people need ranger maps with bridle paths, contours and places of interest. Others want low level street maps with petrol stations and speed camera points.
I'm sure there is a link with a Treasure Map but it's not arrived in my head yet...
Rob..
Hi Rob,
ReplyDeleteThanks for the comments.
Buying a map and expecting all the answers isn't realistic - you need some idea of want you want to make sure you get the right map.
But, even then it takes an "acceptance period" to know you have the right map.
Thanks,
/S
Hi Simon,
ReplyDeleteFirst of all, I'm excited to see from your profile that you blog about Software Test AND social media! These are both topics I blog about but it's rare to find someone else who combines them!
As for maps, I'll tell you that I'm the most navigationally challenged person EVER! I have become totally dependent on my GPS and I tell my kids that they'd better be sure and pack it in my coffin, or I'm sure to head the wrong direction to the afterlife. With all the new GIS technology, I believe traditional maps will soon be considered ancient and old-fashioned. Everyone will be using devices to find their way. As for analogy of maps and test I guess I'll say from experience:
Even people with the most sophisticated maps can still get lost. (Dumb users!)
Hi Yvette,
ReplyDeleteThanks for the comments.
Technology changes - and so new maps and ways of mapping come along the whole time. Think how maps looked before it was accepted that the earth was round - "There be dragons" appeared in the unknown areas.
To me a map is a testing tool - maybe it gives me some hints about direction (if I'm considering options for direction) or it records where I've been afterwards.
I wonder if "There be dragons" (over-rating the unknown) exist for people who don't use mapping ideas in their testing....
As for trying to incorporate social media aspects into the blog - I've only got part way down that track - have a new post on this coming shortly.
Hi Simon,
ReplyDeleteGreat post!
I've been meaning to reply to this for ages.
Do you need a map?
Just some mapping stuff I'd come across before...
Michael Bolton talks about maps here
http://www.developsense.com/2008/03/maps-and-plans.html
and here
http://www.testingeducation.org/wtst5/Testing%20Without%20A%20Map.pdf
Peter