Testing
James Williams
Sven
"James Williams" <jlw.cre...@verizon.net> schrieb im Newsbeitrag
news:fLgH8.17847$md.1...@nwrddc02.gnilink.net...
> Testing
This is quite an interesting topic. It definately depends on the purpose of
the test.
Testing products in production should minimize the risk, that customers get
faulty products at a reasonable test time with test equipment that justifies
the profit that can be made with that product. The software/firmware used in
thos products doesn't have to be tested in production.
Testing a prototype is a more delicate thing. The hardware should be tested
100%. But what is 100%? Actually every component should work in all
specified situations (temperature included). It is obvious, that some little
projects don't justify the time and costs for the testing, that is required
for a perfect test. In some cases, the customer will do the "beta-testing",
since finally, the product has to work in his environment. It would be fair
to tell the customer, that "we have tested it pretty well, but finally, we
have to find out, if it works for your purposes", but it is not always smart
to do so.
Same with software. It is not easy to stimulate all possible states of a
software, either. But we can carefully modify the software for testing, so
that we will get to those states, that rarely occure more easily. But then,
you have to modify the software again and finally, that new version is not
tested.
I still remember when gave a demontration of a money counter that I have
developed for him. I have shown a customer, that there will even be an error
message, when a buffer overrun (extremely unlikely, since I could count ten
times faster than required) occures (the length of more than 64 banknotes
was stored in a buffer, but the main routine didn't take care of it). For
that purpose, I have commented out the function call, when the buffer was
cleared by the main routine. The error message occured and everybody was
happy. I was chatting with the customer a bit and finally I forgot to
activate the subroutine again - well, I have demonstrated that feature using
the in circuit emulator. The prototype was delivered to the customer, it
passed some tests. Then the customer wanted a modification, which I have
done. I went there, installed the new flash chip (!!!) and the modification
was tested and worked fine, too. Now, the customer gathered all his
colelagues and bosses to demonstrate how well that bank note counter was
working. He took a big stack of banknotes and let it run through his machine
at maximum speed and... bingo... buffer overrun error! It didn't take me
five minutes to find the reason for the problem - usually things like that
take days. Anyway... it was no problem, but a bit embarrassing.
The EMI testing, we have to do with every product that we want to sell is
sometimes something that makes a quick and dirty and cheap solution
unpossible. Of course, there are ways to get round it. Prototypes don't have
to be tested, and things that only work as part of a system and that only
experts can install don't have to be tested either, but finally, the system
has to be tested, so I acually don't want that my product is the culprit
when the whole system doesn't pass the EMI tests.
Testing is not easy and it requires sometimes more time and brain than
developing what we have to test. So we should always keep in mind while we
develope something, that we will have to test it.
--
-cu
Sven
s dot petersen at amotec dot de
Stein Erik Andresen
>
>"James Williams" <jlw.cre...@verizon.net> schrieb im Newsbeitrag
>news:fLgH8.17847$md.1...@nwrddc02.gnilink.net...
>> Testing
>
>This is quite an interesting topic. It definately depends on the purpose of
>the test.
[snip]
>Testing is not easy and it requires sometimes more time and brain than
>developing what we have to test. So we should always keep in mind while we
>develope something, that we will have to test it.
ROTFLMAO :-)
S.E.
Sven
"> >This is quite an interesting topic. It definately depends on the purpose
of
> >the test.
> [snip]
> >Testing is not easy and it requires sometimes more time and brain than
> >developing what we have to test. So we should always keep in mind while
we
> >develope something, that we will have to test it.
>
> ROTFLMAO :-)
Hey, I was waiting for something and it is Friday :)))