Nothing hurts like discovering a problem after launch — especially when someone else points it out. It’s a special kind of pain that smacks your bottom line, dings your reputation and sours client relationships.

No matter how much time we’ve spent looking at a product during development, there’s always a risk that other people have a different (and an unfavorable) experience.

Even worse, preventative medicine is getting complicated. The more responsive our web designs become, the more difficult they become to test. Used to be we could review static layouts. Now layouts are elastic, and we need to check our work on many browsers and devices. Here’s how we head off headaches with a few simple testing processes.

1. Track issues with a chart

Debugging complex apps requires strategic thinking. We collaborate with a Google spreadsheet to keep track of problems, solutions, and who's done what.

 

We arrange pages across the top, and browsers/devices along the left. Our color coding is simple:

• Red = problem, such as JavaScript not working
• Yellow = style and non-functional problems
• Green = good to go

The whole treatment gives us a quick visual summary of how the project stands. Knowing where we are helps us plan our time — a critical factor in beating deadlines.

2. Use great tools for quick checks on the fly

Other tools abound:

• Sometimes we use Adobe Edge's live reload feature. Saving a refresh key combo may not seem like a big deal, but it adds up over time.
• Adobe Edge Inspect also helps us hunt down issues across different browser sizes.
• Github makes issues easy to track for clients as well as engineers. We create labels for bugs, questions, duplicate issues, IE issues, and so forth. It allows for screenshots to show progress and — more importantly — lets us see which issues are closed, without actually deleting them.
• FlexyPlexy shows us a website at different viewports with a clever implementation of an oft-disparaged technique: iFrames.
• We've found Microsoft's Modern.ie to be a handy and generally reliable way to view websites and apps in a variety of platforms. The real benefit: Load once, try on many simulated devices.

3. Test it yourself

Finally, the most important technique is also the most common-sense: try your work on real devices and browsers. Simulators are fine for a quick check, but they're not perfect. We only rely on them for quick tests.

Case in point: You'd think a newsletter would be simple, except for all those pesky nested tables. Not long ago we thoroughly tested a newsletter in Litmus, a popular paid email testing service. Everything looked fine, so we ran it … and then discovered it didn't look so good. We missed one </td> that, strangely, Litmus missed, but caused ugly — and embarrassing — spacing in the wild.

 

We also test products early on. A few minutes' checking now and then reveals problems you can address before they compound like interest into a debt you can barely work off. It's not a perfect metaphor, but who cares when you're trying to solve a problem in code on which the rest of your project relies?

We test with real devices because our users don't use simulators. They use real devices. The only real technique for testing a site on different devices is to test on different devices. Invest in some phones and tablets. Try different browsers — they're free, so what's stopping you? You'll save yourself the risk of embarrassment and headaches after launch.

---