I’ve recently finished some remote testing using exploratory testing techniques. I decided to test out a couple of new (to me) techniques. The first one was using Session Tester to track my effort. The other was creating short videos of difficult to articulate bugs.
First a bit about my testing approach. When I start this type of work, I tend to dive head first, perform analysis along side bug reporting. I then take a step back, work out a plan and get the client OK, then go back to testing. Finally, I write a report which includes recommendations, suggestions and naturally bugs. The reason I work this way, is I often get little up front information on the application, so I find the best approach is the “use it to learn it” approach. I tend to give myself a day to work out the application, and report back to my customer my intended plan.
Anyhow, I liked using Session Tester. It was handy to document the work as I went. However I found that it was hard to track my “tasks” with my bugs. I used my own numbering system which I could then link the bugs and notes. However, when I went to write up my report at the end of the testing, I found my notes were incomplete and sometimes hard to understand. Very frustrating when working to tight deadline.
Fortunately, as a backup to all my work, I always have SpectrePro running as I test. I do this because if a client comes back with a question, its handy to be able to go back and review the work I did. So, SpectrePro had captured not only the application under test, but SessionTester with relevant notes and bugs. It was very helpful to review the SpectrePro video in combination with the SessionTester notes and bugs I’d written.
Another concept I tried was to use FastCapture to capture video of any really difficult bugs. FastCapture allows you to capture your steps and add commentary to it. So if your good at describing what you are doing whilst you test, this is an excellent method to really explain to a client and or developer the problem you encountered. Watch out for the heavy breathing though!
My clients really like the video idea and wants me to explore it further. I don’t know if its something I would do for all bugs as its quite resource heavy (on my time and file size) however, its something I am going to persue.
Will video supercede the written bug? Perhaps not. Like the radio star of the eighties, I don’t think the written bug has anything to worry about. However as an additional testing and communicating resource, it has its place in the noughties.