Test Engineer Resolutions

It's been a few months since I posted anything, though I've started several partial blog posts.  One of my resolutions for 2013 is to be more consistent on finishing up those incomplete ideas.

And since I'm on the subject of new year resolutions, I started thinking about that in a work context.  For the past five years or so I have made a point of tallying a list of personal resolutions for the new year.  They are things I want to do better, something I want to learn about, something new to do.  Some are very personal, some are work-specific, some are general.  At the end of the year I'll take time to record how I did and create a list for the next year (often with the same or similar resolutions).  My process is number-oriented, which shouldn't surprise anybody.

So when I looked at how I scored for 2012 and what I would resolve for 2013, I thought I should do the same for test engineering in general (as opposed to specific to me).  After thinking about it over the holidays, I came up with a top five list.

1. Learn more about what I'm testing.  The first pure testing job I had was at HP, running optical test equipment through its paces to find glitches in the firmware.  The hiring manager loved  my experience using their hardware (or competitor hardware) in real world environments.  Partly because of the years I spent doing that, I think that the more you know about what you're testing the better you are as a test engineer.  
2. Avoid "question the test" issues.  A natural response to unexpected or disappointing test data is to question the test system.  You can raise concerns about the accuracy of the system, bugs in the code, the person running it, how the test is performed, etc.  The best way to avoid this is to be proactive with the test systems: discuss issues with design engineers in advance; run regular GR&Rs on the systems; look at the data for your golden samples and see if it makes sense.  And if the issue is raised, don't get offended - just approach it like any other problem to solve.  
3. Data dive once in a while.  If all you do is build/modify/run test systems, then you're missing out on what the data can tell you.  I've talked multiple times about using JMP to analyze data, but regardless of whether use use that, Minitab or just Excel, it's important to sometimes take a look at the data your systems are generating.  Don't rely on just letting the design engineers analyze the data.  Do it for yourself & you might just learn something interesting (see #1 above).
4. Plan your career for the year.  You could argue that everyone should do this, and I wouldn't disagree. Having a plan is important.  As a test engineer some items to plan would be:
• Read at least one test engineering article a week: TMW, EE, etc.
• Attend a conference or two: NI Week, AutoTest, or others
• Sign up for some training (i.e. - LabVIEW)
• Join/be involved in a test engineering group: ASTE, IEEE, etcetera and so on.
5. Socialize.  Again, this one could be generalized for anyone in an office setting.  But test engineers can sometimes just get stuck back in the lab, running our systems, analyzing the data, and stay oblivious to changes going on in manufacturing or R&D.  It's good to keep lines of information open, and sometimes going out to lunch with people from other groups helps.

Wow, that was a long-winded post.  We'll see if I can stick to my resolution of writing more here throughout the year.