Still around after the storm

It's been a busy month, personally and professionally.  Aside from new hires and a reorg at work, on December 11th there was a huge ice storm in the New England area that knocked out my electricity for ten days.   Luckily I got it back before Christmas - some people weren't as lucky.

Anyway, I have several more posts that I'll be getting up this winter.  As I've said before, I usually flag emails/articles/etc. when I find something interesting to say.  I'm about due for another clearing of the in-basket.

 

Shot of the woods near my house the day after the storm.

The power of repeated testing

I know I've talked before about statistics in relation to test engineering (here or here for example).  One thing I haven't really discussed is Gage R&R testing, but something personally happened to me this week that reminded me how useful that testing tool can be.

Where I live is close to the bottom of a hill within a subdivision.  I have found, through repeated testing, that if I a) shift my Toyota Prius into neutral at a specific speed once I turn into the subdivision and b) follow the same path, then I can overcome the two small hills and coast all the way down to the end of my driveway.  It's kind of a geeky thing to know, but I'm an engineer with a cool car built to do stuff like that.

Last week I got new tires.  A day later I took the normal coast route but the car felt different - a little slower while coasting.  I had shifted into neutral within a couple mph, the roads were not slippery so I didn't need to brake excessively for the curves, but it was definitely slower.  So I called the shop &, as I suspected, they need to be balanced better.

This is a perfect example of why you should run a Gage R&R on your test system every once in a while.    Like my regular "coast to the house" test, a regular test against a known standard will show you if there is something a little "off balance" with your system.

A good test engineer studies the details, part 3

A couple of weeks ago I went on a camping trip up in the White Mountains of New Hampshire. I'm on the boy scout committee for my son's troop and one of the scout masters put together an overnight trip just for the committee adults. The plan was to hike up the side of a mountain, set up camp in an unheated cabin built back in the 30s (by the Civilian Conservation Corps, part of Roosevelt's New Deal), fix our own meals, then hike back down the next morning.

This is not something I've ever done before. I love to camp - we went on camping trips every year when I was young, and I take my kids on at least a couple trips every summer. But when I say "camping" the assumptions made are a) it's warm weather, b) I pack lots of stuff in the car, and c) it's at a state park or somewhere similarly well-organized. For this overnight trip we were each expected to hike a couple of miles uphill all the way while carrying our own food, a gallon of water, sleeping gear, and very warm clothes (forecast of ~20°F that night).

So I approached this almost like I would approach designing a new test: look at previous designs, step through the new test algorithm detail by detail, examine my constraints and design with them in mind, and finally buy the equipment I need. I started with the list I usually use for summer camping trips.  I shopped around and bought a good internal frame backpack with plenty of room for a sleeping bag, clothing, water, etc.   I did a preliminary pack of what I had to see how much room I had left.  Then I went through a mental checklist of what could go wrong & what I would need if it did.  Finally, I went out and bought the remainder of my equipment.

This level of detailed preparation paid off. My folding saw came in very handy cutting the wood we burned for heat that night. I stayed nice and toasty with my thermal underwear and sleeping bag (rated to 0°F). And my spare plastic baggies were invaluable in making the chocolate pudding we had for dessert.

 

 The point I am trying to make here is that my attention to details meant that I had everything I needed to be comfortable on an arduous trip. Similarly, that level of detailed planning will usually insure that your test system will give you valid data as well as recover from difficult situations.

A good test engineer studies the details, part 2

I've always been a big fan of PDAs.  I bought a Casio Telememo watch as a "congratulations on graduating college" present for myself.  It held up to 100 phone numbers plus it had calendar and memo functions.  I was hooked.  Since then I've had a host of such portable devices, including wring a program on my Hp48 calculator to hold contact info.  My next device will be either the new Blackberry Storm or maybe an iPod touch.

I view such a device as a necessity for a test engineer.  Sure, it can be a time-wasting toy at times, but I think there are 4 good reasons for using one:

1. Having a calculator with good scientific functions in you pocket is really handy when checking your test results. 
   
2. I have often kept technical specs (often in PDF format) on my Palm - this can be a lot handier than looking it up online.
3. Writing down notes at any time in electronic form is very helpful when you have to refresh your memory 6 months later via a search function.
4. More so that other engineers, test engineers are mobile - commuting from your office to the test lab, meetings, customer's facility, remote site, etc.  But sometimes a laptop is cumbersome, especially if you need to fit in tight spaces.

How does this fit in with my thesis that a good test engineer is detail-oriented?  Referring to the reasons above, I would say that having a tool like this allows you to focus more on the details.

 

Chronological list of my PDAs (1989-2008)

Casio Timebank,  HP48S, HP Jornada 680, HP Jornada 620, Palm TX

 

Testing Intel's latest chip

It's not every day that your profession is spotlighted in the New York Times.  It's even rarer that it is cast in a favorable light.  And yet, today there is a nice piece about Intel's testing of their latest chip, codenamed Nehalim.   The writer interviewed the guy in charge of product testing, and the article references the difficulty in designing the tests.  Of course, they had to talk about the Pentium floating point bug (I certainly remember that one), but that was way back in 1994.  

Anyway, I liked reading that article & I wish John Barton (the test chief) luck.  Testing something of that magnitude has to be keeping him up nights.

A good test engineer studies the details, part 1

Back about 14 years ago I created my first website.  It had maybe a dozen different pages, talked about different interests, had a few jokes on it - the usual stuff that people were doing on the web way back then.  In 1997 I decided to upgrade my computer & ran into all sorts of grief debugging it.  Feeling the need to gripe about it afterwards (blogs weren't invented back then), I wrote a page about it and added it to my website.

I applied for a job at Hewlett Packard a year later.  During the interview I found out that the hiring manager had looked me up online - Google was invented back then -  and found my website & description of the upgrade.  One of the reasons he brought me in for an interview was because he was impressed over how I had a) dug into the problem, b) tried out several different solutions, c) identified the problem (bad EIDE plug on the motherboard) and d) fixed it.  It was that kind of attention to detail and problem solving skills he needed in a test engineer.  I got the job, moved to California, worked there a couple of years, and loved it.

That website is long gone, but last week I dug around and found the original HTML files I had created.  So, here's the complete page that helped me land the job:

=================================================================

The Upgrade From Heck

Early in 1997 I decided that my poor 486DX had seen its last. Fancying myself a clever fellow, I decided to upgrade on my own. I mail ordered a motherboard, Cyrix 686, 72pin memory, and a PCI video card, carefully shopping around to get the best price on each.

Tragedy struck. First, I found that the screwhole locations on motherboards are not standardized. Solution: epoxy plastic standoffs to my sturdy metal case. Then, the board would not recognize my hard drive. Here are the steps it took to fix this:

1. Played around with the BIOS settings. No luck.
2. Borrowed a brand new Western Digital drive from a friend. Still nada.
3. Called tech support, who returned my call several days later with no answer.
4. Borrowed a plug in IDE card from work that goes into an ISA slot. When I plugged the old hard drive into the card (rather than the built-into-the-motherboard EIDE plug), the computer did detect the drive.
5. Faxed all these steps in a long memo to tech support, who shipped out a new motherboard free of charge. Problem solved.

Below is a picture I took of my version of dual-processing. During the month I was working on this problem, I still wanted to work on my computer. So I would have to unplug the new board (bottom), plug in the old board (top), turn on the computer, change the BIOS settings, and go.

Okay, I'm done venting now.

Relieved

Thank goodness it is, finally, November 5th.