Test engineering fears

I originally planned to write this post for Halloween, but my schedule slipped. Today is Friday the 13th, so that's a decent fallback position.

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

My middle child was talking about scary movies and what he thought made them scary right before Halloween. That started my thought train on what I fear as a test engineer. More specifically, what a test engineer at a startup fears. Here's my top five:

5) Bugs caught by management

In a small firm most everyone helps out, even management . When you write code, bugs are inevitable. It's okay when other engineers spot the bugs, but it's really embarrassing when the CEO emails you about a mistake he found in your program.

4) Feature creep

Things are always changing in a startup, and that most definitely applies to the testing process. You come up with better ways to test the DUT, you come up with new things to test on the DUT, you speed up your testing, etc. All of these things are fine, but sometimes they feed into extraneous changes to the test system. A design engineer may think, "Hey, it'd be really cool if I could see this set of data while the test is running," but any change like that takes time, and those changes can eat into the time you need for something else.

3) Bad requirements

Worse than feature creep are bad requirements. Suppose you are told that you need to measure current and temperature of a DUT under specific load conditions. So you get the hardware, set up the software, build the station. THEN you are told that - oops - we also need to measure optical parameters of the DUT under a separate set of conditions as well. Suddenly, you have a serious rework on your hands. That scenario can happen in a startup, and it's a real pain.

2) Data getting lost or corrupted

In every startup I've been a part of, data management is a problem. In the beginning, it's easy to sort your data and analysis work with a combination of spreadsheet files, text files, and a good subfolder setup on your network. As the startup grows, you have to implement a database, which introduces its own growing pains. In the meantime, your company lives and dies on that test data. About 4 years ago I had a problem at a startup where an entire set of test-data subdirectories was accidentally deleted from the network by an engineer working in his own directory. I spent an entire day getting the IT guy to get the network backup from two days before and then figuring out which devices had to be retested. Gruesome.

1) Great test results

This is my top fear. At a tech startup you are developing new technology. Things aren't supposed to work right. You have problems with the manufacturing process, you miss key design issues, or you discover unexpected behavior. When I see great test results from a DUT I get nervous; my first thought is that something is screwed up with the test equipment. So I will do a quick check of the hardware connections, software design, and the algorithms used. Good results can play havoc with my sense of well-being.