Links for today's talk

I'm speaking about testing software on mobile touch devices this afternoon. I'll post my slides or a video or something later.

But here's some links to people doing similar stuff that I want to refer people to if they're interested:

http://blog.omnigroup.com -- where our designers and engineers talk about their perspectives on the iPad and many other things

www.viddler.com/explore/rentzsch/videos/26/ -- the talk that first got me started thinking about how differently we need to design, develop, and test for the iPhone, by an iPhone developer

vimeo.com/8581946 -- I want to point people both to this speaker (and his blog) and this whole series of lectures about ergonomics and design.

OK, catch you on the flip side!

Making your iPhone App Environmentally Friendly

With a traditional desktop application, most of your users will be sitting at a desk, using a keyboard and mouse. So you can test the applications reasonably well by sitting at *your* desk, using your mouse and keyboard. Sure, there's edge cases, like laptops and graphics tablets. But your test lab or office cube is a pretty good approximaation of their home office or work cubicle.

Stop and think for a minute of all the places where you've used your cell phone lately. A lot of places besides your desk, right? In the next 24 hours, I bet I will use mine sitting at my desk, sitting in meetings, waiting for the bus, riding in a friend's car, shopping at a yarn store, and lying in bed. And all of these environments can reveal bugs that you won't find sitting at your desk.
- At a meeting: In a meeting, I might try to pull up important information on my iPhone and every second the app takes to load, my colleagues get more annoyed with me.
- At the bus stop: I may be interrupted at any moment, when the bus shows up. So don't penalize me for quitting the app. Pause my game so I can continue it later. Save my data.
- In a vehicle: Location isn't just something that can change every time I use the app. It can change *while* I'm using the app. Use the app while you're moving, and figure out whether the user will be happier if you update location-related stuff periodically, or let the user tell you when to update.
- In a store: I've probably only got one hand available, because the other's holding a shopping basket. Can I navigate the application without setting my stuff down?
- In bed: I like to read while lying on my side. So "upright" for me is now perpendicular to the floor. I turn an iPhone perpendicular, and in many applications, it happily rotates the screen for me, so text is still parallel to the floor. Not helpful. Amazon's Kindle app actually handles this very nicely. For a few seconds after a rotation, it shows a lock icon. Tap the lock and the text will get locked into position. After that, I can happily turn it any which-way and still read my book.
- On a plane: If you fly much, you know that all electronics get turned off for the first bit, and then they can be on, but with cell and wifi turned off. Can I use your application with no connection to the outside world? The first time I tried to use OmniFocus on a plane, it went into a loop of insanity, trying every minute or so to connect to the server and sync my data. By the time I dismissed the alert that sync had failed, it'd be nearly ready to try again. If you must fail, make sure you fail gracefully.

So figure out which of these environments are right for your app. I don't need to play an immersive multi-player game while browsing the grocery store aisles, but I better be able to check my shopping list! Test in these environments, or at least find ways to simulate these environments in your test lab. This is one case where a tin foil hat might actually be a legitimate approach!

And now a word from our sponsors....

I'm not blogging to make money. Let me make sure that's clear up front.

But I buy a ton of stuff from Amazon, and when it's good stuff, I tell other people about it. Amazon likes that, so they'll pay me for this. And when someone wants to pay me for something I'm doing already, I'm generally willing to go along with that.

So I'm going to try out this Amazon Associates thing. I'm hoping that it will make it easier for me to link to books and such in my posts. I also hope it will improve your experience of looking up the stuff I'm linking to. But if it turns out that it actually interferes with the primary point of this blog (discussing software testing), then I'll give it the boot. So let's test this thing out, okay?

Right now I'm reading Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) and I hope to post a review of it soon. Maybe separate reviews for each chapter, since it's an anthology?

The road to a presentation starts with a single step...

I have an opportunity to give a talk at another company soon. I've got a (very rough) idea of what the talk needs to contain, so I'll be coming back to it soon. But first, I need a bio and a talk 'blurb'. I'd love constructive feedback on this first draft. In particular, there has got to be *something* better than "hot new development platform"!

Touch devices are the hot new development platform. As testers, we need to borrow strategies from testing both desktop software and pre-touch phones. However, we must also go beyond these perspectives, and develop new heuristics specific to touch devices. Liz will share some of the lessons she's learned in iPhone testing and why it's essential to literally get your hands on touch devices while testing touch-based software.

Liz Marley tests the Omni Group's Mac and iPhone productivity software. She's also very eager to begin testing iPad apps as soon as possible! Liz has 6 years of professional testing experience, and 4 years of debugging homework assignments while earning a computer science degree from Harvey Mudd College.

Touchy Testing

I've been thinking for a while about the unique challenges of testing mobile, touch-based devices. I'm crafting this post entirely on my iPhone, and working around the UI designed for keyboard/mouse-based computers. [I ended up having to type it in an email, and tried the email-to-post feature, but now I've resorted to copy/pasting text from a bounced mail message to a browser window on my desktop machine.]

As a Mac and iPhone software tester, I'm itching to get my hands on an iPad as soon as possible. I told one of our engineers today that I think it's essential for testers to literally get their hands on these devices. I did some iPhone testing before I owned one, and did a decent job of finding bugs on borrowed devices and the simulator. But once I got an iPhone and began to use it day-to-day, I discovered all sorts of new user scenarios. Airplanes, reading in bed, Seattle weather, ... I expect the iPad will not be just a giant iPhone, but have a whole new set of interactions. I look forward to the discoveries. And who can turn down a shiny new toy?

Some other people have written much more eloquently on why it's not just a giant iPhone:

http://speirs.org/blog/2010/1/29/future-shock.html

http://www.mcubedsw.com/blog/index.php/site/thoughts_on_the_ipad/

http://heta.metalbat.com/?p=1998

Why Blog?

Gus Mueller led me to Dan Wood's article on blogging the other day. I didn't quite get around to reading it until just now, but in the meantime, I semi-subconsciously thought about why I think that blogging is a good thing to do. Dan's reasons, although very good reasons, are not my reasons.

1. Blogging pushes me to develop my thoughts from un-examined opinions to defensible theses.
2. Dan hopes future customers will read his blog. I hope other future people find my blog: mentors, co-authors of papers, peers, critics, skeptics, co-workers, people I can mentor?
3. Blogging exercises my communication skills. A big part of testing is detective work. But another big part is story-telling. I want to get better at telling clear, convincing, entertaining stories.

Testing for Experts, or When a Spec is Worth the Bother

@jonbell's Ignite Seattle talk collided with a recent testing adventure of mine. I was really frustrated testing a new feature for one of our apps. About the time I read his talk, (oops, forgot to go in person!) I stopped trying to test the feature and started writing up how I thought this feature was supposed to work. Now I'm not so grumpy anymore.

I used to think there was just testing. Then I broke it out into two types of testing: learning and checking. Now I think there's 3.

I still think there's learning. And I still think there's checking. But there's also learning A to check B.

For many of the features I'm supposed to test, the only written spec is the bug. Sometimes it only has a sentence or two. And that's enough for the engineer to write the feature (mostly) correctly and enough for me to (mostly)test it.[0] Writing more details would just lead to time-wasting, abandoned specs.[1] For example, "Add a 'new folder' toolbar button." The engineers I work with all know how a toolbar button typically works, and so do I. We can make reasonable guesses about what the user expects. I check that it feels predictable[2], shake out a few corner cases, and off we go.

But sometimes we're building expert features. I am not an expert in our users' field. I can't trust my gut to know which operation ought to take precedence when two of them interact. When I realize I'm in this situation, I need to learn first, and then test. This is when I really need a spec. Maybe the engineer needed a spec too, and the bug is already full of notes from him and our PM clarifying how the feature needs to work. Or more often, I need to write my own spec.

"But you just said you don't know this stuff. How can you write the spec?"

I'd say I'm *exactly* the person to write the spec, because I'm the one who knows what questions it needs to answer. If I ask the engineer "How is this supposed to work?" I might get part of what I need to know, but I tend to feel like I'm wasting their time if I camp out in their offices too long. On the other hand, if I write up a short wiki page on how I *think* it's supposed to work, they're often quick to jump in with corrections and clarifying comments.

Developing the spec is the learning step. Now I can pretend to be an expert in the field, and properly check the behavior of the new expert feature.

[0] Honestly, now, when was the last time you *fully* tested something?

[1] Thinking of http://www.joelonsoftware.com/articles/fog0000000033.html

[2] borrowing from Jon