Acceptance Testing

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

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!
- jessie

Re: Acceptance Testing
Quoted text here. Click to load it

Consumer products?

* Q/A says the current version meets marketing objectives (battery life,
speed, lethal range, whatever) or marketing agrees to compromise.
* All reported problems from beta or final Q/A are either fixed or
confirmed by engineering as either "documented" or "as designed" and
marketing has signed off on there being no known issue that would
preclude the product from being profitable.
* Automated test equipment ready and operation validated.
* Manufacturing facility ready (tools set up, operators trained if
* Supply chain guaranteed for at least initial production run, and
leadtimes on major components run in.
* All ISO900x process documentation requirements met.
* Everybody who could object to product release is on vacation.

 -- Lewin A.R.W. Edwards ( /)
Learn how to develop high-end embedded systems on a tight budget!
We've slightly trimmed the long signature. Click to see the full one.
Re: Acceptance Testing
For Automotive products a SAT ( software acceptance test ) is required. The
test and results are generally documented in the same SAT file. For a medium
size project the SAT document can be quite large and take weeks to complete
all the tests.

The SAT document generally references all the specification documents for
the system. And the tests are designed to test the complete system

Quoted text here. Click to load it

Re: Acceptance Testing

Quoted text here. Click to load it

In my line (High Integrity Systems:-

  * All reported problems eliminated and product passed final review
  * Customer has witnessed the system testing and has signed acceptance
    that his pre-specified criteria has been met.
  * The full documentation package has been handed over to the customer.

Naturally there are many review stages along the development trail
including the initial acceptance of the customer requirements. It is so
important that the clients specification of requirements is coherent enough
to allow the requirements analysis phases to make proper sense of them.
Unless step one is right you have no hope of delivering what the customer
truly wants.

On many projects that I am involved in there are not only the customer
requirements to consider but legislative requirements to consider. It takes
a great deal of research and questioning of the client to ensure that ALL
the reqwuirements are considered. Once the requirements are well enough
understood it becomes possible to build a matrix of requirements and means
of meeting them (QFD's). It is a fairly simple matter to then devise tests
to be performed for acceptance of the final product that proves each
requirement has been met, even the for the development and manufacturing
processes that produces the product.

We've slightly trimmed the long signature. Click to see the full one.
Re: Acceptance Testing
Quoted text here. Click to load it

In practice:-

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
following flags.

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
customer doesn't.  

\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ \/\/

Site Timeline