<< Unit, Integration and System testing | Test Automation >>

Acceptance Testing

<< Unit, Integration and System testing | Test Automation >>

Sometimes the expectation is that the SIT team will become the companies Quality Assurance
team, even though they have no direct influence on the way software is developed. The assumption
is that by increasing the length and rigour of testing it will improve the quality of released products
and so it does.

But it does nothing to increase the quality of built products so it's not really QA.

In the best of worlds, this team can act as an agent of change. It can introduce measures and
processes which prevent defects from being in written into the code in the first place; they can
work with development teams to identify areas which need fixing; and they can highlight successful
improvements to development processes.

In the worst of worlds the pressure on software development drives longer and longer projects
with extended test cycles where huge amounts of defects are found and project schedules slip. The
testing team attracts blame for finding defects and for long testing cycles and nobody knows how
to solve the problem.

Acceptance Testing

Large scale software projects often have a final phase of testing called "Acceptance Testing".

Acceptance testing forms an important and distinctly separate phase from previous testing efforts
and its purpose is to ensure that the product meets minimum defined standards of quality prior to
it being accept by the client or customer.

This is where someone has to sign the cheque.

Often the client will have his end-users to conduct the testing to verify the software has been
implemented to their satisfaction (this is called "User Acceptance Testing" or "UAT"). Often UAT
tests processes outside of the software itself to make sure the whole solution works as advertised.

While other forms of testing can be more `free form', the acceptance test phase should represent
a planned series of tests and release procedures to ensure the output from the production phase
reaches the end-user in an optimal state, as free of defects as is humanly possible.

In theory Acceptance Testing should also be fast and relatively painless. Previous phases of testing
will have eliminated any issues and this should be a formality. In immature software development,
the Acceptance Test becomes a last trap for issues, back-loading the project with risk.

Acceptance testing also typically focusses on artefacts outside the software itself. A solution often
has many elements outside of the software itself. These might include : manuals and
documentation; process changes; training material; operational procedures; operational
performance measures (SLA's).

These are typically not tested in previous phases of testing which focus on functional aspects of
the software itself. But the correct delivery of these other elements is important for the success of
the solution as a whole. They are typically not evaluated until the software is complete because
they require a fully functional piece of software, with its new workflows and new data
requirements, to evaluate.