In another first I have participated in my first European Weekend Testing session. Unfortunately I had to leave part way through the discussion after testing finished but I saved off the chat transcript to read through later.
We were testing a Flash application (http://www.barcodeart.com/artwork/netart/yourself/yourself.swf) which, to all appearances, was a simple tool for creating a barcode using personal data. Our mission was to find the highest value barcode possible. If you follow the link above you get to the value associated with the barcode by clicking on ‘Scan’ once the final barcode is displayed.
Once we got started I made the classic schoolboy mistake of not searching for documentation about how the application works and only noticed that the FAQ went into quite a bit of detail late on in the session. As a result I could not work out how the pricing was calculated. Lesson number 1: you need to establish what constitutes your test basis – and that should include documentation – before you can test efficiently. This is something that we all know deep down but we need reminded of it sometimes.
The hour’s testing time seemed to go by really quickly but it was amazing how much ground could be covered during that time as a group. The importance of being structured in the approach to testing – even a ‘simple’ application – came through for me very early on in the testing run when I was establishing the structure for a barcode. I drew myself up a table on a piece of paper and filled it in with the parameter values I was using as I went along. As I found patterns emerging, I highlighted them with highlighter pen. Lesson number 2: record what you do – the form doesn’t matter – it saves a lot of time and wracking brains later.
Unfortunately I do not have any tools at home to examine the source code behind the Flash movie so I could not do any static analysis to determine how the barcode and pricing had been implemented. Lesson number 3: if you have got the tools, use them to make your life easier.
I enjoyed the experience of investigating and exploring an application unlike any that I normally come across in my day-to-day work. Reading through the chat transcript conversation moved on to the delights of TMAP with none other than Michael Bolton airing his views! It reminded me of my first SIGIST where Michael warned us all on the danger of introducing too much ‘process’ to our testing.
I look forward to the next time I get a chance to attend a Weekend Testing Event. With thanks to Anna Baik for encouraging me to join a session, Thomas Ponnet and all the other contributors for the welcome and opportunity to learn from others this afternoon.