Monday, December 28, 2009

Software Architecture and Test Engineering

After a hiatus, I'm back. I broke up with my girl friend which gives me much more time to do the things I enjoy doing and a lot less stress. Robotics, Artificial Intelligence, and my blog. Good nerdy engineering enjoyment.

The Test Engineering group I'm in is made up of mainly hardware people. A lot of them write software, some of them think they can write software, a couple of them really can write software. A software architecture is something required by the process but foreign to them. The bosses, who are mainly hardware types, want to make sure we've thought about the software before we start. Mainly because the hardware guys typically start writing software get to a point where it's a big mess and then patch as well as they can.

In the software past, the software architecture was called the preliminary design. Somewhere along the line someone came up with a paradigm shifting idea to rename it to software architecture. No matter what it's called, it's still just a high level view of the software job at hand.

Almost all of our tests are sequential, simple stimulate and check the UUT. TestStand is our standard test sequencer and we use it very simply, sequential testing with some very minor looping.

It can be a simple functional flow or a simple high level flowchart. We do set of similar tests followed by another set of tests, etc. The architecture is simple, non-complex by real software standards, and straight forward. Almost any thing should be acceptable as an architecture.

Occasionally the architecture will be more complex. Once this happens, then more advanced techniques are needed. More advanced flowcharts or especially UML would be a good candidate. Something to show interactions between different processors and different threads (although, where I work, threads are magic and unknown)

Any of this can prove to the bosses that we have thought about it, the flowchart is what they can understand. The people who are suppose to provide this are agonizing over what to provide and how to do it, taking a lot of time. The good software people are saying to let us know what format you want and we'll give it to you.

This is why we need people who can do software and not just hardware guys who code C. We know how to plan the software.