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?