A software evangelist and self-proclaimed code curmudgeon discusses
the value of test and measurement.
Why are test and measurement
In a sense, quality gets more important as the computer gets smaller. It’s
an oversimplification, but if you think
about the ramifications of a slightly
flakey word processor, they are minimal. It crashes, you restart. Maybe
you lose a little bit of editing, perhaps
not even that if it has crash recovery
and auto-save. No harm, no foul.
In the realm of a mission-critical
device, even a small failure can endanger lives or even kill. The cost of
updating is secondary to the risk,
and quality becomes paramount.
You’ve got to know that what you’re
deploying is thoroughly tested.
What is driving the need for
embedded test and measurement?
System complexity is mirroring the
enterprise space. Where we once had
a few specific embedded systems do-
ing isolated tasks, now everything is
interconnected. It’s not just that the
parts can talk to each other, but they
rely on each other. If one component
fails, it can bring the system down.
What advice would you offer?
From my perspective, the process is
what’s frequently missing from software. It’s not just about having good
testing tools available; it’s about having a process that makes sure that
requirements are filled and code is
tested. This means consistent practices, training, coding, and testing.
NAME: Arthur Hicken
CO.: Parasoft Corp.
ROLE: Research and develop
software solutions that help
organizations deliver defect-free
Business needs and requirements
can be codified in the SDLC (
software development life cycle) through
tools like a development testing platform, where you can set policy and
see what development is doing and
what the quality is in real time, rather than waiting until you hit QA
If you treat [software] more like
engineering, you get better results.
This means proper design and plan-
ning, risk assessment, and controlla-
ble, measurable, repeatable process.
It’s been known for decades that this
is the path to quality. Software tends
to have too much of a “let’s test
quality into the product” mentality.
It’s simply not possible.
An interesting corollary to that is
the possibility for prevention in stat-
ic analysis. The current fad trend
in static analysis is flow analysis.
While flow analysis is cool because
it finds potential defects, the men-
tality behind chasing bugs ignores
the better process of building bullet-
The great benefit that static analysis can provide is in preventing bugs
in the first place. When it comes to
safety and mission critical systems,
the prevention route of defensive programming is a much better idea. Í