QA Hates You

Marlena Compton posits If you do testing, you need more monitors.

Au contraire, I say, but I mispronounce it because I do not speak French.

I use a single monitor (across multiple machines, no less, through the magic of KVM).

Ms. Compton says:

Having more monitors leads to better testing because:
More supported browsers are open and easy to compare
More sessions are open so it is easier to see cause and effect problems
I can have more than one or even two or three users signed in with different permission levels.
Even though there are still several browsers open, I can also have some terminals open for grepping through log files and taking notes or logging bugs.

Of all these things, the only time I’ve found multiple monitors to be a worthwhile solution is while running automated tests on a number of machines. Each machine had its own monitor (14″ CRTs back in the day), and the master control monitor (17″ CRT, probably) launched the scripts and displayed a -tailing log while the scripts ran. In the automated environment, where you’re watching the scripts (and maybe the GUIs), this makes sense.

But in my world of manual testing, especially exploratory and ad hockish testing, one monitor is better. A big monitor, to be sure, so you can blow everything up really big, but one monitor just the same.

The reason: Focus.

Ms. Compton says:

In the world of web application testing, this is the difference between noticing something and having it obscured behind too many screens where you will never see it.

The principle extends to across too many screens as well as in open windows that don’t have focus. It’s hard enough to catch one little bit of squirrelly behavior in one little spot in an application page or an application window when it happens right in front of you. If you’ve got to turn your head or rely on your peripheral vision to catch it, you won’t.

Dramatic re-creation

Personally, I focus all my attention on one browser/window at a time. If I could put a photography hood over my head, I would. Come to think of it, maybe I ought to get one. Because I’m zoned in on that thing I’m looking at or testing.

If I need multiple sessions open at once to have different users interacting, I’m still focusing on looking for bugs in one of them at one time. I can do that with multiple browsers open on one machine.

Compatibility testing? Let me tell you how I did it when I was a printer: I took the print sample I was supposed to match and I put the new print sample over it, and I held them together against the light. The Web testing equivalent is to maximize the browser windows, load the pages to compare, and use ALT+TAB to switch between them quickly. Misplaced items will jump around visibly.

So more monitors isn’t necessarily better, especially if your attention has a tendency to

SQUIRREL!

Forget the hashtag #AnnualGoals2013 that I tried and failed to get going on Twitter. Here’s my personal list of strengths and attributes I’d like to improve in the forthcoming year:

An interesting story about the Internet as seen in North Korea:

There’s a curious quirk on every official North Korean website. A piece of programming that must be included in each page’s code.

Its function is straightforward but important. Whenever leader Kim Jong-un is mentioned, his name is automatically displayed ever so slightly bigger than the text around it. Not by much, but just enough to make it stand out.

The article also details the various home-brewed operating systems and whatnot in North Korea.

You know, I think QA’s a pretty high-pressure gig since I’m very eager to make the software perfect before the alpha release even, but I’m not putting my life on the line testing it. I can’t imagine what it’s like to work QA in North Korea.

(Link seen here.)

Noah Sussman has two lists about how developers often bungle time in their applications:

I have repeatedly been confounded to discover just how many mistakes in both test and application code stem from misunderstandings or misconceptions about time. By this I mean both the interesting way in which computers handle time, and the fundamental gotchas inherent in how we humans have constructed our calendar — daylight savings being just the tip of the iceberg.

Read his lists: Falsehoods programmers believe about time and More falsehoods programmers believe about time; “wisdom of the crowd” edition.

Then go ye forth and see if your developers got any of them right.

(Link courtesy Gimlet.)

If you don’t understand nothingness, you cannot be nothingness:

Or maybe this poor Web site is struggling with the works of Heidegger. We’ll never know. All we know is that it’s not doing what it’s supposed to.

You know what is a damn cheap trick? Entering an invalid value in a Zip Code field, especially if your system is trying to validate it.

Here are three Zip codes that do not exist for your testing pleasure:

87258
86705
97052

You’re welcome. Your developers will definitely not thank you.

How do you really, really know a problem? You get your hands dirty at it.

Steve Blank talks about the origins of his success, and strangely enough, they involve doing physical things and encountering the problems he would later help overcome through the engineering:

When I got to my first airbase my job was lugging electronics boxes on and off fighter planes under the broiling hot Thailand sun, to bring them into the technicians inside the air-conditioned shop, to troubleshoot and fix. The thing we dreaded hearing from the techs was, “this box checks out fine, it must be a wiring problem.” Which meant going back to the aircraft trying to find a bent pin in a connector or short in a cable or a bad antenna. It meant crawling over, under and inside an airplane fuselage the temperature of an oven. Depending on the type of aircraft (F-4’s, F-105’s or A-7’s – the worst) it could take hours or days to figure out where the problem was.

A few months later, I was now the guy in the air-conditioned shop telling my friends on the flight-line, “the box was fine, must be a cable.” Having just been on the other side I understood the amount of work that phrase meant. It took a few weeks of these interactions, but it dawned on me there was a gap between the repair manuals describing how to fix the electronics and the aircraft manuals telling you the pin-outs of the cables – there were no tools to simplify finding broken cables on the flightline. Now with a bit more understanding of the system problem, it didn’t take much thinking to look at the aircraft wiring diagrams and make up a series of dummy connectors with test points to simplify the troubleshooting process. I gave them to my friends, and while the job of finding busted aircraft cabling was still unpleasant it was measurably shorter.

My next career lesson: unless I had been doing the miserable, hot and frustrating job on the flightline, I would never have known this was a valuable problem to solve.

Not all of us can be fortunate enough to have done the work that the people using our applications do with our applications, but it’s important to step outside the IT bubble mindset and recognize, as best we can, what they’re trying to do outside the context of our software to best provide them software to do that job.

Here’s a little ode to those guys out in the field to make up for my lack of a QA Music post yesterday: