The Acceptance Test Procedures that I've written, primarily for our dear government, consists of line by line steps to verify functionality of the hardware/software. It consists of sections, where each section/subsection validates a requirement, and the exact, precise, repeatable steps that are taken to verify that the requirement is met. Each line item is signed off and if it fails, notes are made as to why it fails, plan of action and/or acceptance due to a situation outside of the control of the testing process. Since gov't contracts (and others that I've worked on, for example, aeronautics industry is big on ATP's and milestones, in my experience) that I've worked on are based on completion of milestones, the ATP becomes a key vehicle for validating those milestones and hence payment.
Jason McBurney wrote:
I obviously don't have the same concept of ATP as you.
I've also noticed, in perusing the web for examples of an ATP, that my concept seems different. I guess my way of thinking is rather outdated. I did this stuff 20 years ago. However, some example similar to what I've done in the past can be found here[^] and here.[^] Of course, these are for hardware, but I've written them for software as well. Tedious, time consuming, but when you've got a couple hundred thousand dollars riding on acceptance, it's well worth it. And it also is a great document to work with while developing/debugging--you can have a grunt go through the ATP rather than a senior engineer. Here's a link on software ATP's[^] Acceptance’ is a significant stage in the contractual process; commercially, it is likely to