After years of SFDPOT being created by James Bach and used by many testers, James has amended SFDPOT to include “I” for interface testing. A couple of weeks back someone contacted me via Twitter and asked me about “I” for mobile testing. Here’s my response:
Interface. Test the ways we interact with it.
Does the app work well on an array of devices such as phones and tablets?
Does the app work well when used with “one hand?”
Does the app work well when used with “one eye?”
Is the mobile version consist or complementary to the desktop version?
Is the app consistent with UI current constructs in the marketplace?
Does the mobile version address what makes sense when a user is on the go?
On another note, I’ve long thought that “E” for error testing should be added to the SFDPOT mnemonic. Here’s how I would address error testing.
Errors. Test the coded-for known error states and around those error conditions.
Does the app continue gracefully after an error?
Is the message helpful, instructive?
If a user provokes multiple errors in succession, does the app continue?
Can I get to an error state that forces the app to shut down?
What happens when I restart the crashed app – is previous data or state saved?
Is there a method to send an error report?
I think this question about adding “I” was a good question because it raises the awareness of not testing just to the suggestions of a heuristics but continuing on, adding our own thoughts, considering the context and while using a heuristics – thinking beyond a heuristic as needed.