More Software Architecture and Test Engineering

Last time I wrote about some challenges doing software architectures in a primarily hardware group of test engineering. First, we need a definition, so here's one that I had laying around in IEEE 1471:

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolution"

The software developed in Test Engineering, at least where I work, isn't so formal as to have a definition. However, we still need guidelines of what an architecture is.

Basically, a software architecture defines the structure of the system, the relationship between the major components, the behaviour of the components. It focuses on the significant elements, extending out to the needs of the UUT (Unit Under Test), and takes into account the needs of the systems users.

Since a lot of testing is sequential, the structure is usually fairly simple. For that simple structure just about anything can be used to document it. However, any threading or other processes or interaction with other processors should be included which can cause some complexity in the architecture.

The relationship between the various resources and how they need to be used to test the UUT needs to be diagramed. Sometimes this is straight forward, sometimes there's some complex interactions. Any communications between componants need to be noted.

Also the significant attributes of how user is involved (user interface). Anything that has user interactions.

That's it in a nutshell. The main thing is to let the team know what is being developed on a higher level. Also, to try to let the managers know you've thought about what you're doing.