MangledMonkey

November 22, 2008  |  Thoughts

A tool for testing visualization software on the glass – i.e. software with views which have custom content and complex associated mouse behaviour and interactions.

  • We can get users to prod the software, but they will typically go down common use cases and paths
  • We can get testers to explore the software

Or we can let the mangled monkey test tool do something in between!

The tool would interrogate the UI and build a map of the possible commands (e.g. buttons) and properties (edit boxes etc.). It will also scrape the screen looking for “edges” and other interesting artifacts – i.e. search for things which could be controls of some kind and therefore could be interacted with via a mouse.

It creates a starting node (and remembers nodes not yet explored), then tries to grab features and hammer them with mouse actions whilst also invoking commands and properties (marked as available).

An adaptation would be to have a user work with the application and have the mangled monkey observe the choices they make and use this tree as a start point to experiment in and around.

Effectively the mangled monkey is somewhere between randomly hitting keys and hiring a tester.


2 Comments


  1. OK, sounds interesting. If I can do some semi-automated prodding myself: what kind of output does the tool produce, and how do you use that output? Is it reviewed manually? The thing with a human tester is they can typically recognize when they’ve encountered a bad behavior – how will your robot?

  2. Good point – In its current form it wouldn’t validate. The tool is supposed to try to crash the application, not validate usage. If it has some usage data it tries to stick to a path through the application but veer off and hope to return and “follow” the path.

    What I really want is some way to signpost or bookmark parts of the application (external to the code) and provide some guidance as to what the bookmark is attached to and its expected behaviours. A sort of acceptance criteria per feature (again for tricky rendered items).

    How about recording usage behaviour and using some form of collective intelligence algorithm to test around the behaviours it has seen in the past. Needs more thought…