A couple of hands-on tools

tl;dr – two handy tools

On Sunday, I was watching a film of a fine tester testing. I was keeping track of how his testing differed from mine. I realised that I was looking for the functionality of a couple of tools that I sometime use, and that he wasn't using at the time.

Both tools are for the Mac, but I imagine that similar tools are available for PCs too. Although neither are testing tools, they do things that are not only convenient, but by being frictionlessly convenient, allow me to observe and trigger behaviour in usefully-different ways.

The first is Mouseposé from Boinx. Mousposé highlights your on-screen pointer position, and is the close cousin of many tools used by teachers and screencasters to make their actions more obvious.

What makes it useful to me as a tester is that it makes user actions more explicit – not only following the pointer around, but differentiating between one click and double- (and n-) clicks, between right and left button (or however one expresses the peculiar sigil necessary on a trackpad to do the same). It also – and here's the killer – displays the keys you're pressing. These are on the edge of vision, in large letters on a low-screen bezel. They appear very briefly, and captured keys include shift, control, escape, enter and so on. It's great to expose the occasional finger slips that lead to novel behaviour, great for working out what you're doing, and for confirming (or not) that you're doing what you think you're doing. It's especially useful if you, like me, find that your hands don't always do quite what you ask them to do.

If they made a tester version, I'd like it to cope with multi-touch, give me a trail on drag, and ideally have some kind of paper-tape thing to show recent input and save me using a keylogger.

The second is Keycue from Ergonis. Lean on the command key for more than a few seconds, and KeyCue pops up a bezel with every* currently-available command-key combination. Not just the front application, but all the combos that are currently listening. Different options respond as you change your key combo. It's great for ramping up your expert hands-on-keyboard-flying-user tricks, but more than that, it shows you a whole bunch of potential bug triggers.

Key stroke input can cause unusual behaviour not only because it comes through an alternative route (as it happens, the rout is easier to automate, so tends to be covered in developer-side testing/checking) but because it's fast and potentially in conflict with other stuff. Hitting keys in swift succession can expose timing-related bugs (two in Word, one in Excel this morning alone). Hitting meaningful keys that have meaning to something other than the thing you're talking to can also get the pizza spinning. I want to try it on a cyrillic machine and on localised software.

If I had a tester version, I'd prefer that it actually enquired the system internals to find out what was listening, rather than simply parsed menus (and possibly-flaky "User-definable custom shortcut descriptions"). But I don't even know if that's possible.

* if you're not in version 6, every is unfortunately more like most