Date: 13th May 2010
Time: 15:30 – 17:30 GMT
Product: ZoomIt
Mission:
Your boss asked you to give a report on your latest testing activities. He wants to make the decision whether or not to ship by the end of next week, and needs to inform the production line two days in advance. He wants to get the full program:
* high-level understanding
* graphs
* details where necessary
* interactive questions
While preparing for the presentation, you come across ZoomIt, and wonder whether it may aid you in your quest or not.
Please report all your findings (bugs, final testing statement) until 4.30pm GMT to bugrepository, project EWT18
Testers: Jeroen Rosink, Ashik Elahi, Ajay Balamurugadas, Markus Gärtner
Markus Gärtner facilitated the discussion afterwards.
Ajay Balamurugadas started the discussion. He explained that he turned in rather late, and was just left with 30 minutes to test. Since he tested the application in an earlier session, he had some experience with the application and the domain. Ajay mentioned a heuristic he learnt during Weekend Testing: If everyone is feeling trapped, there might not be a trap at all. As the mission seemed to be full of traps, there may not be any traps at all. Having no traps at all can be confusing. Ajay also pointed out that he doesn’t immediately start to test. Rather he spends some time on the questions raised by others in order to help him understand the mission.
Ashik Elahi reported from his personal testing, that he found the tool to be very useful. Ashik explained, that he learned to clarify the mission first before testing anything. Also, the comments from others in the session are very relevant and can help to understand the mission on its own. Ashik explained on the emerging discussion about the degree to clarify the mission, that he starts by trying to understand the mission as much as possible, then starting to test. If any question or confusion arises, he notices that he needs to further clear it up by questions.
Jeroen Rosink reported that he learned that a particular tool can just be tested in relevance to what the tool should do, or under which conditions it shall be operated. Especially he learned the environmental conditions should not be assumed on a tool evaluation mission. The “product environment” may vary greatly from the testing environment. Defocussing may reveal some new insights in the testing process. Asking questions and heuristics to understand the product and the mission may be worthwhile for the future. Finally, Jeroen remarked that technology might be a bias when it comes to comparisons as the tool could have been replaced with a usual whiteboard or flip chart as well.
The chat transcript can be downloaded here.
Image credits: http://farm3.static.flickr.com/2134/2468493584_cece4257c9.jpg
