> > I believe it would be possible to develop a methodology for the Orion
> > where you could test all possible or likely combinations of buttons,
knobs,
> > and menu items, but considering how many ways all those controls
> > interact, it'd probably take a couple of hours to conduct such a test.
> <snip a lot>
> > After each firmware change not only would new or changed features need
> > to be tested, but all existing functions would have to be tested to be
sure
> > none were broken when the firmware was changed.
>
> I don't entirely disagree with your assessment since I found problems with
my
> first-day-ship Orion that should have been obvious and caught before the
radio
> left the shop.
>
> But I think you underestimate the scale of the problem. Since sequence of
> control operation matters, the number of tests required to test every
possible
> permutation grows as N!. N on the Orion is a sizable number.
>
>
> I've drawn some conclusions about the structure of the software from it's
> behavior. I'd love to get my hands on the source code :-)
>
Well, testing even the most likely combination of buttons, knobs, and menu
items would be absolutely tedious, time consuming, and extremely boring.
That doesn't mean it shouldn't be done.
If I understand it right, the processor used in the Orion is the same as the
one in my PDA. I've done some small amount of PDA programming, and
it's pretty much event driven. In other words, the software waits for some
input for the user, then executes the code for that item that was selected
from the screen.
I would assume (and you know what happens when we assume) that the
Orion firmware is similar. The software is there, running, waiting for you
to
turn a knob, push a button, or select a menu item. Then it executes the code
for that selection.
So the code to operate the panoramic stereo receive, for instance, is
probably
separate from the code for the CW or SSB filter selection. So some sections
of the code probably are isolated from one another and don't interact at
all. But
only the person who wrote or maintains the code would know that. The point
is,
it might be possible to divide the testing into different areas, depending
upon
interaction between sections of the software.
And you're right, there will probably always be some oddball combination of
control operation that will do weird things. And every software system I've
ever used or worked with has had bugs in it. But to me, the goal for any
software developer should be to get ALL of the obvious problems squared
away, then maintain some sort of organized testing effort that will keep
those
errors from creeping back in with future updates. Until that happens, the
owners
will be the ones to find and report these obvious problems.
Most of the IBM mainframe commercial software systems I've worked with over
the past 25 years have run into eight or nine hundred thousand lines of
source code
spread across a thousand or more separate programs, and yet we manage to
modify and test them successfully so that most problems reported by our
customers
are of the obscure variety that happen with certain hardware that we may not
have in our own shop, or interaction with other software products that we
can't
predict ahead of time.
Compared to that, I believe the Orion firmware, running on basically a
pretty simple
CPU should be relatively easy to test. Tedious and boring, but easy.
I guess it's all a matter of perspective.
--
Mike - WB4HUC
Austin, TX
|