As part of a project I'm heavily invested in right now, I started learning NI TestStand last fall. My next few posts will be about that experience and my impressions of TestStand.
Introduction
My previous experience with TestStand dates back to early 2008. My company was in discussions with Averna about their Proligent software, which is written to work hand in hand with TestStand. So I talked with the sales guys, read the white papers, and tried out the demo. My impression of Proligent (and TestStand) was that they were designed for large companies with large automation needs. We were a startup, so I respectfully declined.
Two years and one company later, I reconsidered TestStand. I had a big program starting up and had no desire to create a test executive from scratch, especially not one with the complicated requirements I needed. After some research and discussions with the other members of the group, I bought it and learned how to use it.
Over the next few posts I'll talk about a) how I learned TestStand, b) my experiences with it over the past few months, and c) how suited I think it is to small companies (like mine). I'm also thinking about getting the Certified TestStand Developer certification to go along with my CLD for LabVIEW. If I ever do, I'll surely blog about that as well.
Friday, April 22, 2011
Monday, April 18, 2011
Test engineer tropes
A comment someone made a couple weeks ago started me thinking about common rules of thumb that engineers follow. Here's a few that I've seen in practice.
Murphy's Law
If something can go wrong, it will. When I was in high school I thought this was clever and sarcastic way of expressing a dim view of the universe. It wasn't until I was an engineer that I began to appreciate the statement as an elegant way of describing statistical inevitability: if there is a finite chance that something will happen, given long enough time it WILL happen.
Nyquist Sampling
Engineers commonly double the amount of data they take in the name of Nyquist sampling. It may not be necessary, but that's the way it works.
Once is an anomaly, twice is a coincidence, three is a pattern
This is something that I've said for many years, just as a general rule for test engineering. When I did a search for it, the most common mentions of this are either from the novel Goldfinger or The Moscow Rules (which quotes Ian Fleming). But I think it is most applicable when you're debugging something.
Rinse it six times to clean it
There are well over a thousand references to this on Google. Rinse something out with water six times to clean it. It's a simple rule of thumb.
Double the safety factor
My first job after grad school was at an aerospace engineering firm. There were a lot of mechanical engineers there, and I quickly learned of the prevalence of safety factors from them. It was an unspoken rule that, whatever safety factor you calculated, before you finished the design that factor had to be doubled. Better safe than sorry.
Murphy's Law
If something can go wrong, it will. When I was in high school I thought this was clever and sarcastic way of expressing a dim view of the universe. It wasn't until I was an engineer that I began to appreciate the statement as an elegant way of describing statistical inevitability: if there is a finite chance that something will happen, given long enough time it WILL happen.
Nyquist Sampling
Engineers commonly double the amount of data they take in the name of Nyquist sampling. It may not be necessary, but that's the way it works.
Once is an anomaly, twice is a coincidence, three is a pattern
This is something that I've said for many years, just as a general rule for test engineering. When I did a search for it, the most common mentions of this are either from the novel Goldfinger or The Moscow Rules (which quotes Ian Fleming). But I think it is most applicable when you're debugging something.
Rinse it six times to clean it
There are well over a thousand references to this on Google. Rinse something out with water six times to clean it. It's a simple rule of thumb.
Double the safety factor
My first job after grad school was at an aerospace engineering firm. There were a lot of mechanical engineers there, and I quickly learned of the prevalence of safety factors from them. It was an unspoken rule that, whatever safety factor you calculated, before you finished the design that factor had to be doubled. Better safe than sorry.
Subscribe to:
Posts (Atom)
