Difference between revisions of "AcceptanceTesting"

From CitconWiki
Jump to navigationJump to search
m
m
Line 1: Line 1:
 
Business people and testers collaborating
 
Business people and testers collaborating
  
Top 5 Reasons why teams fail with acceptance testing
+
Top 5 reasons why teams fail with acceptance testing
  
 
# No collaboration
 
# No collaboration
Line 8: Line 8:
 
# Expecting acceptance tests to be a full regression suite
 
# Expecting acceptance tests to be a full regression suite
 
# Focusing on tools
 
# Focusing on tools
 +
# Acceptance testing is not considered as an 'value-adding' activity
 +
 +
Acceptance tests are a specification of a system - in order to be a good specification, they should be exemplars, but don't need to be dealing with every single edge case (if they are to remain readable/useable as documentation)
 +
 +
You could split out more exhaustive testing into a separate section, separate suite, or (better?) a separate tool.
 +
 +
Don't reject acceptance testing because you don't like the tool - start with the tasks you need to achieve.  If it is difficult to automate, it doesn't mean it can be ignored - it is still an 'acceptance test' and it still needs to be run.
 +
 +
Definition of 'acceptance test': whatever you've agreed with the client (not just that that can be automated)

Revision as of 05:18, 19 September 2009

Business people and testers collaborating

Top 5 reasons why teams fail with acceptance testing

  1. No collaboration
  2. Focusing on 'how' not on 'what'
  3. Tests unusable as live documentation
  4. Expecting acceptance tests to be a full regression suite
  5. Focusing on tools
  6. Acceptance testing is not considered as an 'value-adding' activity

Acceptance tests are a specification of a system - in order to be a good specification, they should be exemplars, but don't need to be dealing with every single edge case (if they are to remain readable/useable as documentation)

You could split out more exhaustive testing into a separate section, separate suite, or (better?) a separate tool.

Don't reject acceptance testing because you don't like the tool - start with the tasks you need to achieve. If it is difficult to automate, it doesn't mean it can be ignored - it is still an 'acceptance test' and it still needs to be run.

Definition of 'acceptance test': whatever you've agreed with the client (not just that that can be automated)