Acceptance Testing
The V model of project development highlights the close link between development activities and testing. In our context, the interesting link is between requirements engineering and acceptance testing. We refer to acceptance testing as ‘verifying’ the requirements; has the product been created in accordance with its specification. Verification can be contrasted with validation which assesses if the right product is being specified and built, i.e. does this requirements specification refer the product that the customer actually wants?
Acceptance testing normally involves the customers of the product that has been developed. Left to their own devices however, they may not understand how to create and run the tests. Training and support is therefore frequently provided. This support may come from the development team or from an external body. The external body may be able to offer greater objectivity.
An approach to testing involves identification of ‘acceptance criteria’, followed by ‘test conditions’ and then ‘scripts’ and ‘procedures’.
Requirements can be considered to be acceptance criteria once they are written in a form that can be tested. For users of the Prince project management methodology, it is interesting to compare this viewpoint, quite standard in the requirements and testing communities, with the Prince approach of identifying (testable) acceptance criteria during pre-project work.
Testing of the functional requirements is relatively straightforward – a function either works or it doesn’t. Testing of quality requirements is typically more complicated and involves a range of acceptable values. Users will typically need extra support if they wish to formally test the quality aspects of the system . Note that by the time we get to acceptance testing, we should normally expect the system to be fully debugged; system testing should have highlighted the bugs and both the functional and non functional levels.
Test conditions are those aspects related to a requirement that we are going to test; different organisations tend to define their conditions at different levels of detail. An example of a test condition for a hotel reception system is ‘testing for a client that has pre-booked and where a room of the required type is known to be available’. As well as defining conditions for valid cases, we should define conditions that should be rejected by a well written system.
Test cases involve adding specific data to the conditions. Test procedures involve specifying how a given test is to be run. Note that the definition of these terms may vary – certain tools may use their own definitions.