Acceptance Testing

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 ship?

Thanks for all replies!

- jessie

Reply to
jessie
Loading thread data ...

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 necessary).
  • 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 (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
 Click to see the full signature
Reply to
Lewin Edwards

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 performance.

Reply to
David Powell

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.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

In article , jessie writes

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:- Documentation (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 /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.