Skip to main content

22.03.08 - Release & Acceptance Testing

  1. Release Testing - Is the software ready for release
  2. Acceptance Testing - Is the client happy to pay
  3. There are other stages of acceptance though
  4. Subsequent user testing is the start of evolution

Release Testing​

  • Is the programme ready and done?
  • After Unit testing and sub system integration testing
  • Release testing is the whole system works together
  • "Process is concerned with finding errors that result from unanticipated interactions between components"

Primary goal: Convince the company that the software is good enough to give to the customer Team Role: Not let the software go to acceptance test until its ready Way to do this: Show that it meets all of the specs

Nearly impossible to test all interactions comprehensively, instead would do this strategy:

Integration vs Release Testing​

  1. A separate team that has not been involved in the system development should be responsible for release testing
  2. Rather than finding integration bugs, check that system meets the spec
  3. Validation testing, black box rather than white box

Nearly impossible to test all interactions comprehensively, instead would do this strategy:

1) Performance-driven strategy​

  • Once the system is all complete and integrated
  • non-function things like performance
  • Testing the performance limits includes testing functionality to do it

2) High-Level Spec-driven strategy​

  • Develop a series of tests that relate to different specifications

3) Scenario-driven strategy​

22.02.08 - Req. Gathering Customer scenarios and how they can be satisfied

Acceptance Testing​

  • Takes place after Release Testing
  • Final testing stage before the system is accepted for active use
  • Formal test by the customer to agree that it is ready
  • May reveal requirements problems that do not meet the users needs, or the performance is unacceptable
  1. Define Acceptance Criteria. Should take place early in the process before contract of system signed
  2. Plan Acceptance Testing. Might mean importing real data
  3. Derive Acceptance Tests. After criteria and the plan has been designed
  4. Run Tests.; Any training or actual environment of use
  5. Negotiate test results. Negotiate if each problem is good enough for use
  6. Reject/accept system. If the system is good enough for use

Number of important implications:

  1. Have to begin by documenting what you agreed to build and accommodate of reasonable things that were not predicted
  2. The project does not end when you finish system testing
  3. When is the best time to do acceptance testing

Accept/Reject stage - Customers may be willing to accept the software at a certain stage if they require it ASAP, then provide them with an updated version later on

Alpha User Testing​

Real users doing actual tasks Use a section of real people(clients) Practise real usage on small percentage of the team

Beta User Testing​

Where the software is released for limited general use Limited group is allowed to use a release candidate Users feedback problems as bug reports Also used as a form of marketing