Tuesday, October 6, 2009

Real Time Feedback

This is a trick I use in particular for UI bugs.

The Problem
I'm working on a web-based application and am testing it across five browsers - Safari, IE 7/8, and Firefox 3/3.5. At the moment I'm working on layout and styling.

I have identified an issue related to buttons. Specifically, they look like this on IE7:


Normally I would do what I generally do when I find a bug: log it. I'd attach a screenshot, explain which browser(s) were affected, and move on. There'd be a cute title like "buttons look funny", but most of the explanation would be in the screenshot.

And then a developer would decide to work on it, and he'd move pixels around, and he'd recut the button so his CSS sprites were lined up. And he'd generally getting it looking okay. Mark the bug resolved, and it's time to go to lunch!

So along I'd go, and great, it looks fine on IE7 but now the text is way too high and falling off the button on Firefox 3. I reopen the bug (or log a new one), and kick it back to the developer.

Launder, rinse, repeat.

The Approach
Let's bypass the defect tracking system as communication tool technique that we're currently using. The developer and I set up a time to properly fix the buttons. He's got Safari and Firefox 3.5. I launch IE7, IE8, and Firefox 3. We're going to sit next to each other, make a change, and check it until we're both happy with those darn buttons in all browsers.

Here's how it goes:
  • Both of us open our various browsers
  • Both of us point all those browsers to the developer's machine. Now we can see everything in all browsers pretty quickly.
  • We make sure no one's caching CSS or JS (Often this is a configuration setting on the development environment, and probably already set up, but it's worth checking.)
  • Developer makes a change.
  • We both reload all browsers. Nope. Not there yet.
  • Developer makes a change.
  • We both reload all browsers. Success on IE7, but we broke Firefox 3. Darn.
  • Developer makes a change.
  • We both reload...
  • ... etc etc etc ...
  • Developer makes a change.
  • We both reload all browsers. Success!
  • Check in.
What We've Done
By sitting side by side and knocking out the problem, we've substantially reduced the feedback loop duration. It's easy for the developer and for QA both to see the behavior in all the browsers we care about; everyone can look at everyone's machine and we don't have any lost information in terms of visual behavior. I should note that this can work virtually, but in that case it's easier if you can see each other's screens in some way.

Obviously, this technique won't work for all bugs. But for the visual ones that are mostly a matter of messing around with CSS or with JavaScript, it tends to work really well. The total time to get rid of the bug is much much shorter than if you'd both sat at your respective desks and bounced the bug back and forth.

Give it a shot!

4 comments:

  1. Totally agreed, I think lots of things are improved if you see bug tracking as a system for keeping the state of a problem, not as the communication mechanism (aka the wall). Go and talk to each other (if you can) and agree. Then write a summary so that if you look for the issue you can dig up enough information about it later.
    Knowing what information is relevant is much easier in context. But do remember to leave bread crumbs (I mean summaries) in the bug tracking for other people following the issue and for yourself later on!

    ReplyDelete
  2. You have to love how the different versions of IE render CSS. Good Luck! Try adding Opera, or mobile devices. Thats where the fun begins! UI testing is always interesting!

    ReplyDelete
  3. This is a most common bug that every web developer face now a days even i face this problem. I have one trick to overcome this problem I have created this button in flash and convert in jpeg format.

    ReplyDelete
  4. LIked Lather/Rinse/Repeat

    ReplyDelete