Acceptance Testing

Acceptance testing is strategy where each deliverable goes thru a period of testing and rework to bring it up to an acceptable level before it is considered delivered.  Theoretically, and in practice, a deliverable can be accepted after a single test run but most will not and  it is impossible to tell in advance which is which.

In reality every single deliverable goes thru this process, regardless of whether the plan shows the fact, because every deliverable gets used at some point and will either be found to be satisfactory or it won't.  A significant proportion of deliverables fail first time and have to be reworked.  If a plan does not take this inevitable rework into account then it is doomed to slip.

One way to deal with this is to put some 'management contingency' or 'slack resource' into the plan but this is dangerous 'make do'.  Acceptance testing is not slippage, it is an ordinary, if commonly overlooked, way to spend time in a project.  Putting formal acceptance into the plan explicitly is a much better idea than arbitrary slack for a number of reasons.

It is more realistic.
There is a lesser degree of 'personal heat' generated if a deliverable has to be reworked.
Rework can be systematically managed a part of the process rather than being a fire that has to be put out.
It stimulates discussion about the whole issue of testing and acceptance which would otherwise be ignored.
It is easier to distinguish time spent on acceptance testing from real slippage caused by other avoidable factors.

The mechanics

For each deliverable some objective, testable acceptance criteria and testing methodology must be established in the plan.   Note that often a testing methodology can involve a significant number of deliverables in its own right.  In some projects testing turns out to be a larger problem than the original task. If acceptance is not built into such a plan it is absolutely doomed from the start.

Acceptance testing MUST be carried out by an independent person.   On some projects a separate testing group is set up who's sole responsibility is to serve as objective testers for the delivery. This group often creates deliverables to facilitate testing.  The acceptance period for these testing deliverables is the first acceptance period  they are used on which will be longer because of the extra issues generated by the testing deliverables themselves.  Sometimes the testing group can be independent, even, of the project manager.

Administration

Testing documentation is very important.  Testing can become a bit chaotic when there are a large number of deliverables so which deliverables are in what stage of testing needs to be tracked very carefully in a way which the whole team can easily see. It must also be pain what issues stand in the way of each deliverable under test.

Planning

I have already alluded to the fact that acceptance testing can take a variable length of time depending on how many times around the testing/rework loop a deliverable has to go.  Dealing with this in a schedule is not trivial. 

A simple way to deal with acceptance planning is to create acceptance tasks at the end of the development period of each deliverable.  Testing resources as well as development resources are then assigned to this acceptance task.    The length of the acceptance period is typically 50% of that allowed for development - the exact length is invariably controversial within each project.

This is not perfect:  gaps and squeeze points will inevitably appear as different deliverables take more or less time to go through the acceptance process but it is somewhat systematic and gives you some visibility on the acceptance process within the project.