Friday, 16 November 2012

Lessons Learned On A Running Tour Of Amsterdam

Last week I had the pleasure of attending and speaking at EuroSTAR in Amsterdam. This is my third year attending the event and one I won't easily forget. It was great to catch up with testers and meet new ones. I found the keynotes specially good, the seminars were very informative and gave me plenty to think about. The evening social events were, as expected, great!
All this fantastic testing stuff left me with just 1.5 hours spare for sight-seeing, by the time I got into Amsterdam centre I would need to get back again... this called for the Running Tour! I got my shorts on, my free EuroSTAR t-shirt, trainers/snickers, a map of Amsterdam. I checked the map, decided a rough route to run and off I went!
Since testing was in my head (due to conference about testing) I was thinking how testing related to things I observed in my run... See lessons learned below the drawing.

Here are possible software testing lessons learned for each finding above.

1. You can only found certain bugs using different tests types/techniques. Vary your testing and the tools you use.

2. Experience and skills count in testing. 

3. As testers we often raise bugs which can come across negatively. How about saying something positive about the software on a regular basis?

4. There are certain things that you shouldn’t do as a tester. A possible example: don’t use live private data for testing.

5. Isn’t software about the look and feel? So don’t just look… feel!

6. Going off in tangents is a MUST in software testing. What tangents is the question!

7. There are no best practices in software testing. The running tour did me no favours for this area of Amsterdam.

8. Documenting while you test can be very useful especially when you get ‘lost’. Use video recording tools.

9. Often more info is required to make assessments on the software you are testing. It turns out the man was a teacher and had nothing to do with the war.

10. Many features can be accessed via different means, some bugs will only show themselves one or two of those means.

11. Explore, explore, explore! You never know what you’ll find. 

Running Tour: If you haven't much time, then do a running tour. Set a rough route of what you will look for and start running. 


  1. Great post!! Some great lessons to be had there. Thanks for sharing!

    I must admit - I stepped through the drawing first and related your journey to completely different software testing lessons than your own...

    Here's what I saw:
    1) software acts differently to what is expected sometimes, and it could be the requirements which are defective.

    2) Testing approaches and processes might be totally different beween different organisations. Some processes might be frowned upon or outlawed by certain groups.

    3) Sometimes requirement documents dont fully express the functions the way the stakeholders intend it to.

    4) Risk analysis is very important and the risks need to be taken into account when prioritising tasks. :)

    5) Sometimes other project members might do things that we might disapprove of, that stinks (like developers who release code without checking that it works).

    6) It's important to take note of what's good about the software while testing it!

    7) taking a hunch and going off track can be useful in exploration as you might find some nice bugs.

    8) Mind maps are a brilliant way to not lose sight of the testing mission.

    9) It's important to take a deeper look and investigate the important areas of the software further, in order to test it thoroughly.

    10) Lateral thinking skills are very important in being able to think about different perspectives and scenarios, so you can test from all approaches.

    11) Dont fall into the trap of innattentional blindness! remember the little things along the way too as you explore!

  2. Thanks for the comment Dan.
    Interesting to read how you learnt different lessons from the very same tour!