Re: Acceptance Testing
From: Chris Hills (chris_at_phaedsys.org)
Date: Sun, 15 Aug 2004 17:52:24 +0100
In article <email@example.com>, jessie <firstname.lastname@example.org>
>I'm researching Acceptance testing of embedded systems.
>I realize that each project has its own unique properties, but would
>anyone be willing to offer some generalities on the subject?
>In short, Which criteria generally determine that a product is ready to
>Thanks for all replies!
1 it does want the customer asks.
2 it does not (appear to )crash when the customer runs it before you
have been paid.....
Documentation:- the code is self documented.... :-)
It never ceases to surprise me the number of companies who just have an
EPROM and a couple of pages of notes not even the source code!
I have discussed this recently with a couple of clients who don't have
the source code for current projects! Just the eprom!
Part of the reason is that many/some contractors hold onto the source
until the money is banked. There have been some horror stories of
companies taking the program and not paying out (fully) for a variety of
reasons. On the other hand some contractors have disappeared without
handing over any source or documentation. there are good and bad on both
sides. Come to that it is not just the one man outfits that do this.
Not only are all embedded systems different there are almost as many
development procedures and models.
Basically the acceptance test will require that the system meets the
requirements spec... you do have a requirements spec? This is where
things usually start to fall over. Without as solid spec there can be no
proper acceptance test. Especially as requirements tend to change over
the life of a project.... even a 1 day one :-)
Apart from an acceptance test what are the deliverables? These may be
part of the acceptance test.
It should be:-
(to a particular standard, in-house, industry, IEEE or ISO)
Source code in a particular form
(ie ASCII on a CD or floppy or tape etc)
Documentation on the copyrights for the source etc (In the UK for
example the source automatically the copyright of the author)
The tools are another problem. Some times specific tools are required
other times they are not specified. Or just a language. IE we had some
one on a NG the other day who had a spec for 8051 and C++.... Other
times it will be you WILL used ABC's C compiler V45.678b with the
Then there should also be the proof of testing. Unit test, integration
test and system tests these should have been agreed BEFORE work
started. The best model for this is the W model.
However there is a huge gap between theory and practice. I would start
with the customer requirements and then the Legal requirements. Make
sure YOU can't get sued when someone gets hurt or killed in an incident
involving your customers device. Cover your own arse especially if the
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ email@example.com www.phaedsys.org \/\/